New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

first draft of the extension generator #2411

Merged
merged 10 commits into from Feb 26, 2014

Conversation

Projects
None yet
10 participants
@schmunk42
Contributor

schmunk42 commented Feb 13, 2014

Description

Enter the desired values to create a Yii2 extension ready for usage with composer.
There are currently three files generated: composer.json, README.md and AutoloadExample.php.

This is not final yet. I need some input.

Questions

Q: Should we enforce the yii2- prefix for the package name?
I'd say yes. Will keep a consistent naming across extensions. Can still be changed manually.
How can I prepend yii-2 in the input field or render a form field without label?

Q: Which values should be available for type, do we need more?

Q: How to handle the array input for keywords?
We could add the most popular tags from Yii1.
I'd like to do this input with a Select2 widget, but is it available already (in the core).

Q: What do you think about autogenerating the namespace, is the JavaScript implementation sufficient?

Q: Should title also be autogenerated?
ucFirst(packageName)

Q: Where should the extension be generated?

Q: What do you think about the testing explanation.

Validation and Prefix and Namespace rendering have to be improved, but I wanted to clear the above points first.

bildschirmfoto 2014-02-13 um 04 21 33
bildschirmfoto 2014-02-13 um 04 21 45

This was referenced Feb 13, 2014

@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Feb 13, 2014

Member

Q: Should we enforce the yii2- prefix for the package name?

Nope, based on our previous discussion.

Which values should be available for type, do we need more?

We probably don't need this input field. This generator should only be used to generate extensions. Besides extensions, users may also want to generate application templates, which should be handled by a different generator, IMO.

How to handle the array input for keywords?

Make it simple. Just use comma as the separator. No brackets. User can always fine tune the composer file.

What do you think about autogenerating the namespace, is the JavaScript implementation sufficient?

Again, keep it simple. No auto generation (how would you generate it from, anyway?)

Should title also be autogenerated?

No.

Where should the extension be generated?

Under vendor/<vendor name>/<package name>

What do you think about the testing explanation.

I don't understand ...

Member

qiangxue commented Feb 13, 2014

Q: Should we enforce the yii2- prefix for the package name?

Nope, based on our previous discussion.

Which values should be available for type, do we need more?

We probably don't need this input field. This generator should only be used to generate extensions. Besides extensions, users may also want to generate application templates, which should be handled by a different generator, IMO.

How to handle the array input for keywords?

Make it simple. Just use comma as the separator. No brackets. User can always fine tune the composer file.

What do you think about autogenerating the namespace, is the JavaScript implementation sufficient?

Again, keep it simple. No auto generation (how would you generate it from, anyway?)

Should title also be autogenerated?

No.

Where should the extension be generated?

Under vendor/<vendor name>/<package name>

What do you think about the testing explanation.

I don't understand ...

@samdark samdark added the ext:gii label Feb 13, 2014

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Feb 13, 2014

Contributor

But I'd then set yii2- as the default value (with explanation, that it is a prefix), like recommended in the docs.

The type field is very crucial IMO, because this is the one field you really can use for filtering, tags and name is pretty much useless.
For example, even the current core-extensions are tagged with yii, but they should at least be tagged with yii2 otherwise the developers and users will get confused which package they can use.
This is linked to the first point, it would be much easier to see, if a package is a Yii2 package, if it is visible in the name.
Applications and themes should be handled by another template, I agree to that.

Will modify the keyword section.

Autogenerating (it's merely a type hint) the namespace should just help the user to get familiar with namespaces. You can still change that if you want to.
But it is also usually very intuitive, when you have namespaces structured like in the example in the docs.
What's about only showing a Suggest Namespace button/link, it think that would be helpful.

Sorry, but in vendor is like the only place, where you should not create the extension.
The code created is just a temporary thing, you have to push it immediately into a repo and use it from there, otherwise composer does not know about the files, you'll have no autoloading, etc ....
Maybe it would be better to explain how to push the stuff to a server instead of using a local repo.

I meant the explanation have you've generated an extension, I'll add some screens...

bildschirmfoto 2014-02-13 um 14 01 24

Contributor

schmunk42 commented Feb 13, 2014

But I'd then set yii2- as the default value (with explanation, that it is a prefix), like recommended in the docs.

The type field is very crucial IMO, because this is the one field you really can use for filtering, tags and name is pretty much useless.
For example, even the current core-extensions are tagged with yii, but they should at least be tagged with yii2 otherwise the developers and users will get confused which package they can use.
This is linked to the first point, it would be much easier to see, if a package is a Yii2 package, if it is visible in the name.
Applications and themes should be handled by another template, I agree to that.

Will modify the keyword section.

Autogenerating (it's merely a type hint) the namespace should just help the user to get familiar with namespaces. You can still change that if you want to.
But it is also usually very intuitive, when you have namespaces structured like in the example in the docs.
What's about only showing a Suggest Namespace button/link, it think that would be helpful.

Sorry, but in vendor is like the only place, where you should not create the extension.
The code created is just a temporary thing, you have to push it immediately into a repo and use it from there, otherwise composer does not know about the files, you'll have no autoloading, etc ....
Maybe it would be better to explain how to push the stuff to a server instead of using a local repo.

I meant the explanation have you've generated an extension, I'll add some screens...

bildschirmfoto 2014-02-13 um 14 01 24

@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Feb 13, 2014

Member

I'm wondering if we really need this generator (sorry...)

Gii is designed to generate code to be part of the application it is running in. Based on the discussion and your screenshot, it seems all this generator does is mainly to fill in the composer.json file which should be placed somewhere outside of the application.

It perhaps is more convenient that we provide a template and users copy it to the place they want and modify it directly. As long as README and composer.json are commented clearly, there should be little problem to get started. This is like we provide the basic and advanced app templates rather than using Gii to generate them.

Member

qiangxue commented Feb 13, 2014

I'm wondering if we really need this generator (sorry...)

Gii is designed to generate code to be part of the application it is running in. Based on the discussion and your screenshot, it seems all this generator does is mainly to fill in the composer.json file which should be placed somewhere outside of the application.

It perhaps is more convenient that we provide a template and users copy it to the place they want and modify it directly. As long as README and composer.json are commented clearly, there should be little problem to get started. This is like we provide the basic and advanced app templates rather than using Gii to generate them.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Feb 13, 2014

Contributor

The main advantage of the generator is, that it guides the user through the process of creating an extension. It is similar to composer init but more advanced, because it also prepares a README and the autoloading.
A thing I struggled with, when I started using composer. I think this will help developers getting used to the process.

Forking an skeleton-extension is also not perfect, because every extension will be a fork of the skeleton, very confusing, IMHO.

And to be honest, one of the biggest problems in Yii1 was, that there were almost no guidelines for creating extensions, which made it very hard to use them in combination sometimes, because every developer did it in another way - just because of missing guidelines.

I saw so many weird ideas for Yii2 extensions already, eg. using \yii as the namespace for the extension. Who has heard of PSR-4 already, I think many users don't even know about PSR-0, they'll use class-maps, because they're used to it.
So many people won't read the docs fully, the generator will just help them and the community to maintain a minimal level of consistency.

Yii itself is so straight and clean. The next generation of extensions should follow its example.

PS: I don't think it makes sense to create an application with Gii. But Gii itself does not have to be limited to generating application related code.

Contributor

schmunk42 commented Feb 13, 2014

The main advantage of the generator is, that it guides the user through the process of creating an extension. It is similar to composer init but more advanced, because it also prepares a README and the autoloading.
A thing I struggled with, when I started using composer. I think this will help developers getting used to the process.

Forking an skeleton-extension is also not perfect, because every extension will be a fork of the skeleton, very confusing, IMHO.

And to be honest, one of the biggest problems in Yii1 was, that there were almost no guidelines for creating extensions, which made it very hard to use them in combination sometimes, because every developer did it in another way - just because of missing guidelines.

I saw so many weird ideas for Yii2 extensions already, eg. using \yii as the namespace for the extension. Who has heard of PSR-4 already, I think many users don't even know about PSR-0, they'll use class-maps, because they're used to it.
So many people won't read the docs fully, the generator will just help them and the community to maintain a minimal level of consistency.

Yii itself is so straight and clean. The next generation of extensions should follow its example.

PS: I don't think it makes sense to create an application with Gii. But Gii itself does not have to be limited to generating application related code.

@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Feb 13, 2014

Member

Ok, I'm fine with either approaches. Let's see how other people feel about this PR.

Member

qiangxue commented Feb 13, 2014

Ok, I'm fine with either approaches. Let's see how other people feel about this PR.

@philippfrenzel

This comment has been minimized.

Show comment
Hide comment
@philippfrenzel

philippfrenzel Feb 13, 2014

Contributor

👍 even as I would prefer a "forkable" repository, as I normaly would like to manage the extensions "outside" a complete project... I have them all seperated, as most of them are really reusable code snipets independent of the current project im working on...

Contributor

philippfrenzel commented Feb 13, 2014

👍 even as I would prefer a "forkable" repository, as I normaly would like to manage the extensions "outside" a complete project... I have them all seperated, as most of them are really reusable code snipets independent of the current project im working on...

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Feb 13, 2014

Contributor

👍 😄 Maybe our workflows are different, but since composer I am always developing extensions (or yii2-dev) directly in vendor.

What do you mean with "manage outside a complete project"?
If you develop an extension you need a project or application to run the extension, anyway.
Or do you code "outside" then commit to a repo and update your app afterwards for testing?!

The generator just generates temporary code which has to be pushed to a repo, but this is the same workflow, like you'd do it manually.

Contributor

schmunk42 commented Feb 13, 2014

👍 😄 Maybe our workflows are different, but since composer I am always developing extensions (or yii2-dev) directly in vendor.

What do you mean with "manage outside a complete project"?
If you develop an extension you need a project or application to run the extension, anyway.
Or do you code "outside" then commit to a repo and update your app afterwards for testing?!

The generator just generates temporary code which has to be pushed to a repo, but this is the same workflow, like you'd do it manually.

@philippfrenzel

This comment has been minimized.

Show comment
Hide comment
@philippfrenzel

philippfrenzel Feb 13, 2014

Contributor

well, for me it's really more easy to develop and take care of the extension outside the project, as I normaly use my widgets in multiple smaller sites... so I try to keep application related "extensions" as modules... but thats just my own opinion... :) anyway i like the result as template, that I can then move outside to a "new" folder;)

Contributor

philippfrenzel commented Feb 13, 2014

well, for me it's really more easy to develop and take care of the extension outside the project, as I normaly use my widgets in multiple smaller sites... so I try to keep application related "extensions" as modules... but thats just my own opinion... :) anyway i like the result as template, that I can then move outside to a "new" folder;)

@Quexer69

This comment has been minimized.

Show comment
Hide comment
@Quexer69

Quexer69 Feb 13, 2014

Contributor

Hey Guys, I often used schmunk42/gii-template-collection for yii(1) as codegenerator and still find it very useful! Would be nice to have this extension in yii2 :)

Contributor

Quexer69 commented Feb 13, 2014

Hey Guys, I often used schmunk42/gii-template-collection for yii(1) as codegenerator and still find it very useful! Would be nice to have this extension in yii2 :)

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Feb 13, 2014

Member

I think it's very useful for motivating people to create and share extensions.

Member

samdark commented Feb 13, 2014

I think it's very useful for motivating people to create and share extensions.

@Ragazzo

This comment has been minimized.

Show comment
Hide comment
@Ragazzo

Ragazzo Feb 13, 2014

Contributor

Not sure about this one, it only holds some things like creating composer.json and README.md that are not hard part of creating extension. If this generator will aslo make auto-publishing extension and registering it on packagist that would be great.

Contributor

Ragazzo commented Feb 13, 2014

Not sure about this one, it only holds some things like creating composer.json and README.md that are not hard part of creating extension. If this generator will aslo make auto-publishing extension and registering it on packagist that would be great.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Feb 13, 2014

Contributor

If this generator will aslo make auto-publishing extension and registering it on packagist that would be great.

The API does not support that, AFAIK.

Contributor

schmunk42 commented Feb 13, 2014

If this generator will aslo make auto-publishing extension and registering it on packagist that would be great.

The API does not support that, AFAIK.

@Ragazzo

This comment has been minimized.

Show comment
Hide comment
@Ragazzo

Ragazzo Feb 13, 2014

Contributor

The API does not support that, AFAIK.

maybe then pospone this one until it will be? it would be great though. Can you create in composer repo issue?

Contributor

Ragazzo commented Feb 13, 2014

The API does not support that, AFAIK.

maybe then pospone this one until it will be? it would be great though. Can you create in composer repo issue?

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@Ragazzo

This comment has been minimized.

Show comment
Hide comment
@Ragazzo

Ragazzo Feb 13, 2014

Contributor

right, so as i see it will not be done in nearest future? ok then.

Contributor

Ragazzo commented Feb 13, 2014

right, so as i see it will not be done in nearest future? ok then.

@crisu83

This comment has been minimized.

Show comment
Hide comment
@crisu83

crisu83 Feb 14, 2014

I also think that an extension generator would be a great addition. Having developed quite a few extensions myself I must say that it would had been very useful to have a generator like this when I started with my first extension. There are quite a few good practices when it comes to developing extensions that many do not know about, especially those new to Yii.

As a side node; I also tend to develop my extensions under vendor now a days because I constantly keep improving my them during the development of larger projects.

crisu83 commented Feb 14, 2014

I also think that an extension generator would be a great addition. Having developed quite a few extensions myself I must say that it would had been very useful to have a generator like this when I started with my first extension. There are quite a few good practices when it comes to developing extensions that many do not know about, especially those new to Yii.

As a side node; I also tend to develop my extensions under vendor now a days because I constantly keep improving my them during the development of larger projects.

@jabbon

This comment has been minimized.

Show comment
Hide comment
@jabbon

jabbon Feb 17, 2014

@schmunk42 great addition to gii is exactly the help what I'm looking for.

jabbon commented Feb 17, 2014

@schmunk42 great addition to gii is exactly the help what I'm looking for.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Feb 25, 2014

Contributor

Updated. Please let me know, if there are still open issues.

Contributor

schmunk42 commented Feb 25, 2014

Updated. Please let me know, if there are still open issues.

@index0h

This comment has been minimized.

Show comment
Hide comment
@index0h

index0h Feb 25, 2014

Keywords don't save between preview and generate commands.
If I put keywords and push preview - field reverts to default "yii2,extension".
Chrome 33.0.1750.117

Have some enhancement issues:

  • LICENSE file creation with license content
  • Optional "root" directory. Now in composer.json namespace is relates to "". It is not always convenient, especially when your have many files like CHANGELOG.md, README.md, LICENSE, composer.json, composer.lock, .gitignore, .travis.yml, .scrutinizer.yml, helpers for IDE, test environment, etc. In NodeJS usually used "lib" directory, in C++ "src". Yii2 extensions could use something like that.
  • Optional tests directory structure: phpunit or codeception

index0h commented Feb 25, 2014

Keywords don't save between preview and generate commands.
If I put keywords and push preview - field reverts to default "yii2,extension".
Chrome 33.0.1750.117

Have some enhancement issues:

  • LICENSE file creation with license content
  • Optional "root" directory. Now in composer.json namespace is relates to "". It is not always convenient, especially when your have many files like CHANGELOG.md, README.md, LICENSE, composer.json, composer.lock, .gitignore, .travis.yml, .scrutinizer.yml, helpers for IDE, test environment, etc. In NodeJS usually used "lib" directory, in C++ "src". Yii2 extensions could use something like that.
  • Optional tests directory structure: phpunit or codeception
@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Feb 25, 2014

Member

I think it's ready to be merged. All the future enhancements could be done by separate pull requests.

@qiangxue is neutral about taking it. I want more opinions. @mdomba, @resurtm, @tonydspaniard, @cebe, @klimov-paul, @creocoder.

Member

samdark commented Feb 25, 2014

I think it's ready to be merged. All the future enhancements could be done by separate pull requests.

@qiangxue is neutral about taking it. I want more opinions. @mdomba, @resurtm, @tonydspaniard, @cebe, @klimov-paul, @creocoder.

@cebe

View changes

Show outdated Hide outdated extensions/gii/generators/extension/Generator.php
#if (Yii::$app->hasModule($this->moduleID)) {
# $link = Html::a('try it now', Yii::$app->getUrlManager()->createUrl($this->moduleID), ['target' => '_blank']);
# return "The module has been generated successfully. You may $link.";
#}

This comment has been minimized.

@cebe

cebe Feb 25, 2014

Member

what is this? # comments and a link to a module?

@cebe

cebe Feb 25, 2014

Member

what is this? # comments and a link to a module?

This comment has been minimized.

@schmunk42

schmunk42 Feb 25, 2014

Contributor

Sorry, will remove this.

@schmunk42

schmunk42 Feb 25, 2014

Contributor

Sorry, will remove this.

@cebe

View changes

Show outdated Hide outdated extensions/gii/generators/extension/Generator.php
$output1 = <<<EOD
<p><em>The extension has been generated successfully.</em></p>
<p>To enable it in your application, you need to create a git repository
and require via composer.</p>

This comment has been minimized.

@cebe

cebe Feb 25, 2014

Member

and require it via composer.

@cebe

cebe Feb 25, 2014

Member

and require it via composer.

@cebe cebe added this to the 2.0 Beta milestone Feb 25, 2014

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Feb 25, 2014

Member

looks good to me, the comment as noted above should be removed.

Member

cebe commented Feb 25, 2014

looks good to me, the comment as noted above should be removed.

@samdark

View changes

Show outdated Hide outdated extensions/gii/generators/extension/Generator.php
/**
* This generator will generate the skeleton files needed by an extension.
* @property tbd

This comment has been minimized.

This comment has been minimized.

@cebe

cebe Feb 25, 2014

Member

we can leave it here, will be automatically removed by phpdoc tool.

@cebe

cebe Feb 25, 2014

Member

we can leave it here, will be automatically removed by phpdoc tool.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Feb 25, 2014

Contributor

@index0h Thanks! I added a keywords safe validator.
For the other points I think they are valuable additions, but could easily be handled by the community once this is merged.

Contributor

schmunk42 commented Feb 25, 2014

@index0h Thanks! I added a keywords safe validator.
For the other points I think they are valuable additions, but could easily be handled by the community once this is merged.

samdark added a commit that referenced this pull request Feb 26, 2014

@samdark samdark merged commit 692821e into yiisoft:master Feb 26, 2014

1 check passed

default Scrutinizer: Errored — Travis: Passed
Details
@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Feb 26, 2014

Member

Merged. @schmunk42 please create a separate issue for enhancements.

Member

samdark commented Feb 26, 2014

Merged. @schmunk42 please create a separate issue for enhancements.

@schmunk42 schmunk42 referenced this pull request Feb 26, 2014

Closed

Gii extension generator enhancements #2555

0 of 5 tasks complete

@schmunk42 schmunk42 deleted the schmunk42:feature/gii-extension-generator branch Feb 26, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment