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

Gii from the command line #1280

Closed
cebe opened this Issue Nov 21, 2013 · 63 comments

Comments

Projects
None yet
6 participants
@cebe
Member

cebe commented Nov 21, 2013

Follow up on #43 (comment)

@ghost ghost assigned cebe Nov 21, 2013

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Nov 21, 2013

Contributor

Just to add this here.

One of hardest things when I was coding giic was that the answers values in $_POST which files have to be recreated, were an md5 of the file path (or similar) which made it pretty hard to determine when running Gii via CLI.

Contributor

schmunk42 commented Nov 21, 2013

Just to add this here.

One of hardest things when I was coding giic was that the answers values in $_POST which files have to be recreated, were an md5 of the file path (or similar) which made it pretty hard to determine when running Gii via CLI.

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Nov 21, 2013

Member

@qiangxue what do we do if a module defines web controllers and console controllers? We'd currently put them in the same directory as a module can run any controller in any context. This way console controllers are accessable from the web and web controllers show up in console help command.
Thought about checking for web or console controller in application when we create controller, but that logic lies in the module which has no idea about whether it is console or web context.

Member

cebe commented Nov 21, 2013

@qiangxue what do we do if a module defines web controllers and console controllers? We'd currently put them in the same directory as a module can run any controller in any context. This way console controllers are accessable from the web and web controllers show up in console help command.
Thought about checking for web or console controller in application when we create controller, but that logic lies in the module which has no idea about whether it is console or web context.

@klimov-paul

This comment has been minimized.

Show comment
Hide comment
@klimov-paul

klimov-paul Nov 21, 2013

Member

I suppose “yii\base\Module::controllerNamespace” can be converted into a virtual property using setter and getter. Current code from “yii\base\Module::init()” then can be moved into “getControllerNamespace()”. This will allow you to specify different controller namespace for web and console mode.

Member

klimov-paul commented Nov 21, 2013

I suppose “yii\base\Module::controllerNamespace” can be converted into a virtual property using setter and getter. Current code from “yii\base\Module::init()” then can be moved into “getControllerNamespace()”. This will allow you to specify different controller namespace for web and console mode.

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Nov 21, 2013

Member

Should not only be a solution that works for gii but a general convention.

Member

cebe commented Nov 21, 2013

Should not only be a solution that works for gii but a general convention.

@klimov-paul

This comment has been minimized.

Show comment
Hide comment
@klimov-paul

klimov-paul Nov 21, 2013

Member

You can change “yii\base\Module::init()”:

public function init()
{
    if ($this->controllerNamespace === null) {
        $class = get_class($this);
        if (($pos = strrpos($class, '\\')) !== false) {
            $this->controllerNamespace = substr($class, 0, $pos) . '\\' . (empty($_SERVER['args']) ? 'controllers' : 'commands');
        }
    }
    $this->preloadComponents();
}
Member

klimov-paul commented Nov 21, 2013

You can change “yii\base\Module::init()”:

public function init()
{
    if ($this->controllerNamespace === null) {
        $class = get_class($this);
        if (($pos = strrpos($class, '\\')) !== false) {
            $this->controllerNamespace = substr($class, 0, $pos) . '\\' . (empty($_SERVER['args']) ? 'controllers' : 'commands');
        }
    }
    $this->preloadComponents();
}
@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Nov 21, 2013

Member

I think @klimov-paul 's approach is fine: the controllerNamespace can be dynamically set based on the type of the current application.

Member

qiangxue commented Nov 21, 2013

I think @klimov-paul 's approach is fine: the controllerNamespace can be dynamically set based on the type of the current application.

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Nov 21, 2013

Member

In general that sounds okay but when I want to specify controller namespace manually all controllers have to go in one directory.

Member

cebe commented Nov 21, 2013

In general that sounds okay but when I want to specify controller namespace manually all controllers have to go in one directory.

@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Nov 21, 2013

Member

Well, this is about module which you should generally not allow people to configure controllerNamespace as it doesn't make sense.

Member

qiangxue commented Nov 21, 2013

Well, this is about module which you should generally not allow people to configure controllerNamespace as it doesn't make sense.

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Nov 21, 2013

Member

I thought about configuring it myself when I create the module (not in gii case but in general).
But I can overwrite init() in that case myself when I need it.
Looks good to me now.

Member

cebe commented Nov 21, 2013

I thought about configuring it myself when I create the module (not in gii case but in general).
But I can overwrite init() in that case myself when I need it.
Looks good to me now.

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Nov 21, 2013

Member

Hm... isn't this going to break the idea of codeception that is running WebApplication in console?
The check must not rely on PHP_SAPI or $_SERVER['args'].

Also $controllerMap should be able to define controllers for web and console context...

Member

cebe commented Nov 21, 2013

Hm... isn't this going to break the idea of codeception that is running WebApplication in console?
The check must not rely on PHP_SAPI or $_SERVER['args'].

Also $controllerMap should be able to define controllers for web and console context...

cebe added a commit to cebe/yii2 that referenced this issue Nov 22, 2013

@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Nov 22, 2013

Member

Just check the type of Yii::$app.

Member

qiangxue commented Nov 22, 2013

Just check the type of Yii::$app.

@klimov-paul klimov-paul referenced this issue Dec 30, 2013

Closed

Gii imrovements #1692

0 of 1 task complete
@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Mar 6, 2014

Member

@cebe Should we postpone this?

Member

qiangxue commented Mar 6, 2014

@cebe Should we postpone this?

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Mar 6, 2014

Member

I'm seriously busy currently and this is not critical for beta so we can postpone this to RC.

Member

cebe commented Mar 6, 2014

I'm seriously busy currently and this is not critical for beta so we can postpone this to RC.

@cebe cebe modified the milestones: 2.0 RC, 2.0 Beta Mar 6, 2014

@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Mar 6, 2014

Member

No problem. Could you also review your other beta items and postpone them if needed? Thanks.

Member

qiangxue commented Mar 6, 2014

No problem. Could you also review your other beta items and postpone them if needed? Thanks.

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Mar 6, 2014

Member

will do.

Member

cebe commented Mar 6, 2014

will do.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Mar 7, 2014

Contributor

I think it's no problem to post-pone this, just make sure the implementation requires no API changes.

Just my 2 cents, since this was a very important issue for me in Yii1.

Von meinem iPhone gesendet

Am 07.03.2014 um 01:59 schrieb Carsten Brandt notifications@github.com:

will do.


Reply to this email directly or view it on GitHub.

Contributor

schmunk42 commented Mar 7, 2014

I think it's no problem to post-pone this, just make sure the implementation requires no API changes.

Just my 2 cents, since this was a very important issue for me in Yii1.

Von meinem iPhone gesendet

Am 07.03.2014 um 01:59 schrieb Carsten Brandt notifications@github.com:

will do.


Reply to this email directly or view it on GitHub.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Mar 13, 2014

Contributor

@cebe Since we have to get the values, which are normally entered into the form, from another source, what would you recommend?

  • PHP Array / file (very flexible in generating repeating content)
  • JSON File
  • Something else?
Contributor

schmunk42 commented Mar 13, 2014

@cebe Since we have to get the values, which are normally entered into the form, from another source, what would you recommend?

  • PHP Array / file (very flexible in generating repeating content)
  • JSON File
  • Something else?
@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Mar 13, 2014

Member

Command line arguments?

Member

samdark commented Mar 13, 2014

Command line arguments?

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Mar 13, 2014

Contributor

Yeah, also thought about those, but they change depending on the model.

Maybe with a prefix like PHP:

./yii gii/generate \
  --generator=crud \
  -d modelclass=MyModel \
  -d searchmodelclass=MyModelSearch \
  -d template=default \
  --answers=1a2b3c4f,9876abcd,...

How should we deal with the files (answers)?

Contributor

schmunk42 commented Mar 13, 2014

Yeah, also thought about those, but they change depending on the model.

Maybe with a prefix like PHP:

./yii gii/generate \
  --generator=crud \
  -d modelclass=MyModel \
  -d searchmodelclass=MyModelSearch \
  -d template=default \
  --answers=1a2b3c4f,9876abcd,...

How should we deal with the files (answers)?

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Mar 14, 2014

Contributor

@samdark @cebe Is it possible to run commands from a command?
It would be pretty helpful if we could create an command in the application which runs multiple gii/generate commands.

Contributor

schmunk42 commented Mar 14, 2014

@samdark @cebe Is it possible to run commands from a command?
It would be pretty helpful if we could create an command in the application which runs multiple gii/generate commands.

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Mar 14, 2014

Member

@qiangxue it seems running controller from another controller topic pops up again...

Member

samdark commented Mar 14, 2014

@qiangxue it seems running controller from another controller topic pops up again...

@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Mar 14, 2014

Member

Controller::run().

Member

qiangxue commented Mar 14, 2014

Controller::run().

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Mar 14, 2014

Member

I would not use command line arguments for this at least not required. It is much easier to use when prompted for input that also has necessary explanations messages.
I already have a branch laying around where I started with this. Should be used like this;

# ./yii gii/model

Hi! :)

table name? tbl_user
model namespace [app\models]? app\models\subnamespace
...

Member

cebe commented Mar 14, 2014

I would not use command line arguments for this at least not required. It is much easier to use when prompted for input that also has necessary explanations messages.
I already have a branch laying around where I started with this. Should be used like this;

# ./yii gii/model

Hi! :)

table name? tbl_user
model namespace [app\models]? app\models\subnamespace
...

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Mar 14, 2014

Contributor

But the main feature is running the generation in a batch process.

Contributor

schmunk42 commented Mar 14, 2014

But the main feature is running the generation in a batch process.

@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Mar 18, 2014

Member

I would also like to see the syntax suggested by @samdark (#1280 (comment)) (not quite sure whether we need defaults thought).

To implement it, I think the following methods of the controller needs to be overwritten:

  • actions(): returns the supported generator IDs as the array keys (the array values could the configuration for GeneratorAction).
  • options(): returns the supported options by the specified generator

The GeneratorAction also needs to implement __set() so that the option values can be stored to it.

Member

qiangxue commented Mar 18, 2014

I would also like to see the syntax suggested by @samdark (#1280 (comment)) (not quite sure whether we need defaults thought).

To implement it, I think the following methods of the controller needs to be overwritten:

  • actions(): returns the supported generator IDs as the array keys (the array values could the configuration for GeneratorAction).
  • options(): returns the supported options by the specified generator

The GeneratorAction also needs to implement __set() so that the option values can be stored to it.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Mar 18, 2014

Contributor

@qiangxue I see, so I don't need public properties, but I can declare options dynamically, depending on the action which has been chosen, which is also created dynamically from the gii config.

Contributor

schmunk42 commented Mar 18, 2014

@qiangxue I see, so I don't need public properties, but I can declare options dynamically, depending on the action which has been chosen, which is also created dynamically from the gii config.

@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Mar 18, 2014

Member

Yeah, there's additional work about generating help info for generator and its options, but let's focus on the first part first.

Member

qiangxue commented Mar 18, 2014

Yeah, there's additional work about generating help info for generator and its options, but let's focus on the first part first.

@crisu83

This comment has been minimized.

Show comment
Hide comment
@crisu83

crisu83 Mar 18, 2014

The info could be generated easily using a similar syntax as in Linux:

yii gii/generate -h/--help or yii gii/generate/model -h/--help

The contents of the help could be built using the attributes from the generators. I would actually like to see that all the information about generators are available through the generators and used in both the web and console UI.

crisu83 commented Mar 18, 2014

The info could be generated easily using a similar syntax as in Linux:

yii gii/generate -h/--help or yii gii/generate/model -h/--help

The contents of the help could be built using the attributes from the generators. I would actually like to see that all the information about generators are available through the generators and used in both the web and console UI.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Mar 18, 2014

Contributor

@qiangxue This is just another iteration. #2789

It uses this syntax now:

./yii gii/crud \
--template="default" \
--modelClass="\app\models\TestBase" \
--searchModelClass="\app\models\TestBaseSearch" \
--controllerClass="\app\controllers\TestBaseController"

I left some TODO markers in the code. Please give me some hints here...

  • how to populate in options() I wasn't able to access the generator
  • somehow the params are set in controller and action, but I can only access them from the controller
  • getUniqueId()

Open points

  • full help texts
  • show options help for actions
  • interactive mode
  • reenable --generate (or files)
Contributor

schmunk42 commented Mar 18, 2014

@qiangxue This is just another iteration. #2789

It uses this syntax now:

./yii gii/crud \
--template="default" \
--modelClass="\app\models\TestBase" \
--searchModelClass="\app\models\TestBaseSearch" \
--controllerClass="\app\controllers\TestBaseController"

I left some TODO markers in the code. Please give me some hints here...

  • how to populate in options() I wasn't able to access the generator
  • somehow the params are set in controller and action, but I can only access them from the controller
  • getUniqueId()

Open points

  • full help texts
  • show options help for actions
  • interactive mode
  • reenable --generate (or files)
@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Mar 18, 2014

Contributor

@qiangxue about Controller::run() for batches of yii or gii commands I tried this: https://gist.github.com/schmunk42/9628134
But as you can see in the log output there's always only an Actor.php model created, looks like the controller is not reset, at least it does not use the values provided?!

Contributor

schmunk42 commented Mar 18, 2014

@qiangxue about Controller::run() for batches of yii or gii commands I tried this: https://gist.github.com/schmunk42/9628134
But as you can see in the log output there's always only an Actor.php model created, looks like the controller is not reset, at least it does not use the values provided?!

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Mar 18, 2014

Contributor

@qiangxue I got a solution, will be in The next push

Contributor

schmunk42 commented Mar 18, 2014

@qiangxue I got a solution, will be in The next push

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Mar 19, 2014

Contributor

Status about the help:

$ ./yii
[...]
- gii                            Allows you to run Gii from the command line.

Fine.

$ ./yii help gii

DESCRIPTION

Allows you to run Gii from the command line.
Example command:
$ ./yii gii/<generator> --property1=foo --property2=bar --generate=true


SUB-COMMANDS

- gii/controller: Action run a Gii generator.
- gii/crud: Action run a Gii generator.
- gii/extension: Action run a Gii generator.
- gii/form: Action run a Gii generator.
- gii/giiant: Action run a Gii generator.
- gii/model: Action run a Gii generator.
- gii/module: Action run a Gii generator.

To see the detailed information about individual sub-commands, enter:

  yii help <sub-command>

OK, but not perfect. Taken from the docblock in GenerateAction, therefore everywhere the same text.

$ ./yii help gii/crud

USAGE

yii gii/crud [...options...]


OPTIONS

--color: boolean
  whether to enable ANSI color in the output.
  If not set, ANSI color will only be enabled for terminals that support it.

--generate: boolean (defaults to 0)
  whether to generate all files and overwrite existing files

--interactive: boolean (defaults to 1)
  whether to run the command interactively.

Not good, all generator attributes are missing.

Related #2821 - to get rid of the console-gii definition.

Contributor

schmunk42 commented Mar 19, 2014

Status about the help:

$ ./yii
[...]
- gii                            Allows you to run Gii from the command line.

Fine.

$ ./yii help gii

DESCRIPTION

Allows you to run Gii from the command line.
Example command:
$ ./yii gii/<generator> --property1=foo --property2=bar --generate=true


SUB-COMMANDS

- gii/controller: Action run a Gii generator.
- gii/crud: Action run a Gii generator.
- gii/extension: Action run a Gii generator.
- gii/form: Action run a Gii generator.
- gii/giiant: Action run a Gii generator.
- gii/model: Action run a Gii generator.
- gii/module: Action run a Gii generator.

To see the detailed information about individual sub-commands, enter:

  yii help <sub-command>

OK, but not perfect. Taken from the docblock in GenerateAction, therefore everywhere the same text.

$ ./yii help gii/crud

USAGE

yii gii/crud [...options...]


OPTIONS

--color: boolean
  whether to enable ANSI color in the output.
  If not set, ANSI color will only be enabled for terminals that support it.

--generate: boolean (defaults to 0)
  whether to generate all files and overwrite existing files

--interactive: boolean (defaults to 1)
  whether to run the command interactively.

Not good, all generator attributes are missing.

Related #2821 - to get rid of the console-gii definition.

@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Mar 19, 2014

Member

The help command and the base console controller class may need to be refactored. Currently, the help command is responsible for parsing and obtaining the help doc from individual controller/action. We could move this logic to the base controller class so that controllers can override it to provide customized help doc.

Member

qiangxue commented Mar 19, 2014

The help command and the base console controller class may need to be refactored. Currently, the help command is responsible for parsing and obtaining the help doc from individual controller/action. We could move this logic to the base controller class so that controllers can override it to provide customized help doc.

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Apr 18, 2014

Member

The help command and the base console controller class may need to be refactored. Currently, the help command is responsible for parsing and obtaining the help doc from individual controller/action. We could move this logic to the base controller class so that controllers can override it to provide customized help doc.

👍

Member

cebe commented Apr 18, 2014

The help command and the base console controller class may need to be refactored. Currently, the help command is responsible for parsing and obtaining the help doc from individual controller/action. We could move this logic to the base controller class so that controllers can override it to provide customized help doc.

👍

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Apr 18, 2014

Contributor

Btw: Should the command be moved to extensions/gii/commands?

Contributor

schmunk42 commented Apr 18, 2014

Btw: Should the command be moved to extensions/gii/commands?

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 18, 2014

Member

Yes, I think so. Also Gii may register its commands in its bootstrap method.

Member

samdark commented Apr 18, 2014

Yes, I think so. Also Gii may register its commands in its bootstrap method.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Apr 19, 2014

Contributor

Yes, I think so. Also Gii may register its commands in its bootstrap method.

@samdark I just tried this, but without luck. Should the core extensions have their bootstrap method automatically called? I don't see a bootstrap entry in extensions.php for any core extension.
There are also no bootstrap entries in the composer.json files, eg. here.

I also created a related question in the forum: http://www.yiiframework.com/forum/index.php/topic/53534-auto-configure-extensions-with-bootstrap/

Contributor

schmunk42 commented Apr 19, 2014

Yes, I think so. Also Gii may register its commands in its bootstrap method.

@samdark I just tried this, but without luck. Should the core extensions have their bootstrap method automatically called? I don't see a bootstrap entry in extensions.php for any core extension.
There are also no bootstrap entries in the composer.json files, eg. here.

I also created a related question in the forum: http://www.yiiframework.com/forum/index.php/topic/53534-auto-configure-extensions-with-bootstrap/

@samdark

This comment has been minimized.

Show comment
Hide comment
@samdark

samdark Apr 19, 2014

Member

Yes if these are in bootstrap in config. See how Gii registers its own URL rules now.

Member

samdark commented Apr 19, 2014

Yes if these are in bootstrap in config. See how Gii registers its own URL rules now.

@cebe

This comment has been minimized.

Show comment
Hide comment
@cebe

cebe Apr 19, 2014

Member

Yes, I think so. Also Gii may register its commands in its bootstrap method.

is this really needed? calling it using the route should be enough. Help command also searches for commands in modules autmatically.

Member

cebe commented Apr 19, 2014

Yes, I think so. Also Gii may register its commands in its bootstrap method.

is this really needed? calling it using the route should be enough. Help command also searches for commands in modules autmatically.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Apr 20, 2014

Contributor

But why has yii2-gii no bootstrap entry in its composer.json file and it also does not show up in vendor/yiisoft/extensions.php?
I tried this with another module of mine and it's basically working fine, but when is the bootstrap method from gii called?

Contributor

schmunk42 commented Apr 20, 2014

But why has yii2-gii no bootstrap entry in its composer.json file and it also does not show up in vendor/yiisoft/extensions.php?
I tried this with another module of mine and it's basically working fine, but when is the bootstrap method from gii called?

@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Apr 20, 2014

Member

Because you may not want to use gii even if you have installed gii via composer.

Member

qiangxue commented Apr 20, 2014

Because you may not want to use gii even if you have installed gii via composer.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Apr 20, 2014

Contributor

Ok, so the bootstrap() method from gii is only called, when gii is actually used/requested, right?

Contributor

schmunk42 commented Apr 20, 2014

Ok, so the bootstrap() method from gii is only called, when gii is actually used/requested, right?

@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Apr 20, 2014

Member

Nope. It is called only if you list gii in bootstrap in the app config.

Member

qiangxue commented Apr 20, 2014

Nope. It is called only if you list gii in bootstrap in the app config.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Apr 20, 2014

Contributor

OK, got it - I didn't catch some of the bootstrap() updates. Thanks to all.

Contributor

schmunk42 commented Apr 20, 2014

OK, got it - I didn't catch some of the bootstrap() updates. Thanks to all.

@qiangxue

This comment has been minimized.

Show comment
Hide comment
@qiangxue

qiangxue Sep 14, 2014

Member

Done.

Member

qiangxue commented Sep 14, 2014

Done.

@qiangxue qiangxue closed this Sep 14, 2014

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