Quantcast

A ZF2 Cli module

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

A ZF2 Cli module

robertbasic
O hai! :)

I started to play around with the idea of a Cli module/component/whatever.

Some code: https://github.com/robertbasic/zf2-cli

So far everything is just stuffed under one namespace, hopefully it'll end
up as something usable :)

The experienced ones among you will notice that the code (the Bootstrap.php
and the Application.php) is just a blatant copy of the code from Zend\Mvc.

I just took out the request/response/routing stuff and (tried to) replaced
it with Zend\Console\Getopt. But hey, it works!

The end idea is to have a CliApplication which can be used for modules that
need command line interaction. These Cli modules _should_ be aware of all
the HttpApplication and the HTTP modules. Why? Because the first Cli module
I want to create will need to be aware of all the "installed" modules :)

Major work I plan to do:

1) Break the current Application::run into Application::run and
Application::dispatch so we can have pre. and post.dispatch events.

2) Wrap the action dispatching in to a try/catch block so any exception
thrown from inside the action (or deeper) will be caught and nicely output
to the console (see 4))

3) Make the "cli" controllers similar to the current ActionControllers, e.g.
make them locator aware and dispatchable. Also, to have a
(set|get)ConsoleOptions available to all the cli controllers, so any command
line arguments/flags/options can be accessed from inside the action.

4) Create some kind of a "response", something that will implement
Zend\Stdlib\MessageDescription down the line, so it can be sent to STDOUT
normally (print it, pipe it to some other process...). Bonus points for
making it print with colours! Green for all good, red for errors, stuff like
that. Maybe we have this already?

5) Once 4) is done, implement send() to Cli\Application.

With the current code, running php bin/cli.php --foo-bar will run the
fooBarAction in the Controller\Cli controller.

One thing I'm not sure about is are these cli controllers. I have 3
different ideas for them at the moment:

1) Each Cli module has *one* Controller\Cli (the actual controller name
configurable thanks to Zend\Di, but the _recommended_ name in this case
would be Controller\Cli). All the callable actions are to be implemented in
this controller. Basically, just as it is now:

    > php bin/cli.php --foo-bar will run the fooBarAction in the
Controller\Cli controller.

2) Each Cli module has as many controllers as there are callable actions and
the actual action name would be something like executeAction() or similar.
In this case, the action name would not be configurable. Example:

    > php bin/cli.php --foo-bar will run the executeAction in the
Controller\FooBar controller.

3) Each Cli module can have as many controllers and actions as the developer
wants. This way would complicate the whole Console\Getopt things because the
calling would be something like:

    > php bin/cli.php -c foo -a bar --param value

and this would call the barAction in the Controller\Foo controller, passing
"param" with "value" (note: the param passing stuff would be available in
any case).

Also, I never ever used Zend\Tool (tested it once it came out, said meh, and
forgot about it). If something/anything/everything from above is already in
Zend\Tool, or can be taken out from there or this whole thing can be made
with a simple Zend\Tool provider, speak now :)

Comments? Thoughts? Ideas?

Let the bashing begin :)

Cheers,
Robert

--
~Robert Basic;
http://robertbasic.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

Wil Moore III
>
> I started to play around with the idea of a Cli module/component/whatever.
> Some code: https://github.com/robertbasic/zf2-cli


Interesting approach. Quick question: How does this differ from something
like:
https://github.com/symfony/symfony/tree/master/src/Symfony/Component/Console
?
--
Wil Moore III

Best Practices for Working with Open-Source Developers
http://www.faqs.org/docs/artu/ch19s02.html

Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html

DO NOT TOP-POST and DO trim your replies:
http://linux.sgms-centre.com/misc/netiquette.php#toppost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

robertbasic
On Sun, Oct 2, 2011 at 11:56 PM, Wil Moore III <[hidden email]>wrote:

> Interesting approach.
>

Thanks, I guess. :)


> Quick question: How does this differ from something like:
>
> https://github.com/symfony/symfony/tree/master/src/Symfony/Component/Console?
>
>

I don't know. I'm not familiar with the inner workings of the Console
component, I've used it only a couple of times while learning Symfony2. Why?
Do you like it how the Console component works? If you know about it more,
do tell :)

--
~Robert Basic;
http://robertbasic.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

Wil Moore III
>
> On Sun, Oct 2, 2011 at 11:56 PM, Wil Moore III <[hidden email]>wrote:
>
>> Interesting approach.
>>
>
> Thanks, I guess. :)
>

LOL...yeah, I meant I like the approach and it seems creative :) Sorry, my
comment could have meant anything, but it was a complement :)


>
>
>>  Quick question: How does this differ from something like:
>>
>> https://github.com/symfony/symfony/tree/master/src/Symfony/Component/Console?
>>
>>
>
> I don't know. I'm not familiar with the inner workings of the Console
> component, I've used it only a couple of times while learning Symfony2. Why?
> Do you like it how the Console component works? If you know about it more,
> do tell :)


Yeah, the Symfony2 component is pretty cool. It hands input/output well,
does coloring of output, and allows you to write your sub-commands using the
command pattern.

Best,

--Wil
--
Wil Moore III

Best Practices for Working with Open-Source Developers
http://www.faqs.org/docs/artu/ch19s02.html

Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html

DO NOT TOP-POST and DO trim your replies:
http://linux.sgms-centre.com/misc/netiquette.php#toppost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

robertbasic
On Mon, Oct 3, 2011 at 2:06 PM, Wil Moore III <[hidden email]>wrote:

> On Sun, Oct 2, 2011 at 11:56 PM, Wil Moore III <[hidden email]>wrote:
>>
>>> Interesting approach.
>>>
>>
>> Thanks, I guess. :)
>>
>
> LOL...yeah, I meant I like the approach and it seems creative :) Sorry, my
> comment could have meant anything, but it was a complement :)
>

Thanks again then :D


>
>
>>
>>
>>>  Quick question: How does this differ from something like:
>>>
>>> https://github.com/symfony/symfony/tree/master/src/Symfony/Component/Console?
>>>
>>>
>>
>> I don't know. I'm not familiar with the inner workings of the Console
>> component, I've used it only a couple of times while learning Symfony2. Why?
>> Do you like it how the Console component works? If you know about it more,
>> do tell :)
>
>
> Yeah, the Symfony2 component is pretty cool. It hands input/output well,
> does coloring of output, and allows you to write your sub-commands using the
> command pattern.
>
>
Hopefully this will also handle in/output well, colouring is one of the
planned things to do... But these sub-commands you speak of, what are they?


--
~Robert Basic;
http://robertbasic.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

weierophinney
Administrator
In reply to this post by robertbasic
-- Robert Basic <[hidden email]> wrote
(on Sunday, 02 October 2011, 09:15 PM +0200):

> I started to play around with the idea of a Cli module/component/whatever.
>
> Some code: https://github.com/robertbasic/zf2-cli
>
> So far everything is just stuffed under one namespace, hopefully it'll end
> up as something usable :)
>
> The experienced ones among you will notice that the code (the Bootstrap.php
> and the Application.php) is just a blatant copy of the code from Zend\Mvc.
>
> I just took out the request/response/routing stuff and (tried to) replaced
> it with Zend\Console\Getopt. But hey, it works!
>
> The end idea is to have a CliApplication which can be used for modules that
> need command line interaction. These Cli modules _should_ be aware of all
> the HttpApplication and the HTTP modules. Why? Because the first Cli module
> I want to create will need to be aware of all the "installed" modules :)
>
> Major work I plan to do:
>
> 1) Break the current Application::run into Application::run and
> Application::dispatch so we can have pre. and post.dispatch events.

Not really necessary. You can use priorities for this. :)

    $events->attach('dispatch', $callback, 100);  // pre-dispatch
    $events->attach('dispatch', $callback, -100); // post-dispatch

> 2) Wrap the action dispatching in to a try/catch block so any exception
> thrown from inside the action (or deeper) will be caught and nicely output
> to the console (see 4))

You might look at how I did this in Zend\Mvc\Application -- basically, I
triggered a dispatch.error event, and the expectation is that a listener
would return a response.

> 3) Make the "cli" controllers similar to the current ActionControllers, e.g.
> make them locator aware and dispatchable. Also, to have a
> (set|get)ConsoleOptions available to all the cli controllers, so any command
> line arguments/flags/options can be accessed from inside the action.

I'd argue you should go the same route as Zend\Mvc here. Have a wrapper
for Console\Getopt that returns a RouteMatch object containing the
arguments it captured, and have a special event like MvcEvent that has
accessors for it. This would promote re-use of controllers for multiple
purposes.

> 4) Create some kind of a "response", something that will implement
> Zend\Stdlib\MessageDescription down the line, so it can be sent to STDOUT
> normally (print it, pipe it to some other process...). Bonus points for
> making it print with colours! Green for all good, red for errors, stuff like
> that. Maybe we have this already?

We don't, though there's some functionality like this in Zend\Tool. I
think Jeroen Keppens would be interested in helping out with this.

> 5) Once 4) is done, implement send() to Cli\Application.
>
> With the current code, running php bin/cli.php --foo-bar will run the
> fooBarAction in the Controller\Cli controller.
>
> One thing I'm not sure about is are these cli controllers. I have 3
> different ideas for them at the moment:
>
> 1) Each Cli module has *one* Controller\Cli (the actual controller name
> configurable thanks to Zend\Di, but the _recommended_ name in this case
> would be Controller\Cli). All the callable actions are to be implemented in
> this controller. Basically, just as it is now:
>
>     > php bin/cli.php --foo-bar will run the fooBarAction in the
> Controller\Cli controller.

Why limit to one controller per module? Just curious what the rationale
is.

> 2) Each Cli module has as many controllers as there are callable actions and
> the actual action name would be something like executeAction() or similar.
> In this case, the action name would not be configurable. Example:
>
>     > php bin/cli.php --foo-bar will run the executeAction in the
> Controller\FooBar controller.

Why "executeAction" and not just dispatch()? dispatch() will be called
anyways...

> 3) Each Cli module can have as many controllers and actions as the developer
> wants. This way would complicate the whole Console\Getopt things because the
> calling would be something like:
>
>     > php bin/cli.php -c foo -a bar --param value
>
> and this would call the barAction in the Controller\Foo controller, passing
> "param" with "value" (note: the param passing stuff would be available in
> any case).

Another possibility: try using apt/yum/git/etc. style, and do words:

    php bin/cli.php foo bar --extra --params=here

I'm not sure how complex this would be to implement, but it would remove
some of the extra dash options.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

robertbasic
On Mon, Oct 3, 2011 at 3:39 PM, Matthew Weier O'Phinney <[hidden email]>wrote:

> -- Robert Basic <[hidden email]> wrote
> (on Sunday, 02 October 2011, 09:15 PM +0200):
> >
> > Major work I plan to do:
> >
> > 1) Break the current Application::run into Application::run and
> > Application::dispatch so we can have pre. and post.dispatch events.
>
> Not really necessary. You can use priorities for this. :)
>
>    $events->attach('dispatch', $callback, 100);  // pre-dispatch
>    $events->attach('dispatch', $callback, -100); // post-dispatch
>
>
Really? If so, awesome. Thanks for the tip :)


> > 2) Wrap the action dispatching in to a try/catch block so any exception
> > thrown from inside the action (or deeper) will be caught and nicely
> output
> > to the console (see 4))
>
> You might look at how I did this in Zend\Mvc\Application -- basically, I
> triggered a dispatch.error event, and the expectation is that a listener
> would return a response.
>

As I said (or maybe I missed that), I do plan to follow the Mvc\Application
implementation as close as possible.


>
> > 3) Make the "cli" controllers similar to the current ActionControllers,
> e.g.
> > make them locator aware and dispatchable. Also, to have a
> > (set|get)ConsoleOptions available to all the cli controllers, so any
> command
> > line arguments/flags/options can be accessed from inside the action.
>
> I'd argue you should go the same route as Zend\Mvc here. Have a wrapper
> for Console\Getopt that returns a RouteMatch object containing the
> arguments it captured, and have a special event like MvcEvent that has
> accessors for it. This would promote re-use of controllers for multiple
> purposes.
>

I've seen that, but didn't fully grasp the idea behind it. So, with this the
same controller could be used from both Http and Cli?


>
> > 4) Create some kind of a "response", something that will implement
> > Zend\Stdlib\MessageDescription down the line, so it can be sent to STDOUT
> > normally (print it, pipe it to some other process...). Bonus points for
> > making it print with colours! Green for all good, red for errors, stuff
> like
> > that. Maybe we have this already?
>
> We don't, though there's some functionality like this in Zend\Tool. I
> think Jeroen Keppens would be interested in helping out with this.
>

OK.


>
> > 5) Once 4) is done, implement send() to Cli\Application.
> >
> > With the current code, running php bin/cli.php --foo-bar will run the
> > fooBarAction in the Controller\Cli controller.
> >
> > One thing I'm not sure about is are these cli controllers. I have 3
> > different ideas for them at the moment:
> >
> > 1) Each Cli module has *one* Controller\Cli (the actual controller name
> > configurable thanks to Zend\Di, but the _recommended_ name in this case
> > would be Controller\Cli). All the callable actions are to be implemented
> in
> > this controller. Basically, just as it is now:
> >
> >     > php bin/cli.php --foo-bar will run the fooBarAction in the
> > Controller\Cli controller.
>
> Why limit to one controller per module? Just curious what the rationale
> is.
>

Well, currently just that it's easier to implement (have to parse only one
argument instead of 2 :))


>
> > 2) Each Cli module has as many controllers as there are callable actions
> and
> > the actual action name would be something like executeAction() or
> similar.
> > In this case, the action name would not be configurable. Example:
> >
> >     > php bin/cli.php --foo-bar will run the executeAction in the
> > Controller\FooBar controller.
>
> Why "executeAction" and not just dispatch()? dispatch() will be called
> anyways...
>

Hrm, right.


>
> > 3) Each Cli module can have as many controllers and actions as the
> developer
> > wants. This way would complicate the whole Console\Getopt things because
> the
> > calling would be something like:
> >
> >     > php bin/cli.php -c foo -a bar --param value
> >
> > and this would call the barAction in the Controller\Foo controller,
> passing
> > "param" with "value" (note: the param passing stuff would be available in
> > any case).
>
> Another possibility: try using apt/yum/git/etc. style, and do words:
>
>    php bin/cli.php foo bar --extra --params=here
>
> I'm not sure how complex this would be to implement, but it would remove
> some of the extra dash options.
>

Well, Zend\Tool already works without the dashes, no? Will have a look into
it.

Thanks for the comments! :D

--
~Robert Basic;
http://robertbasic.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

weierophinney
Administrator
-- Robert Basic <[hidden email]> wrote
(on Monday, 03 October 2011, 04:12 PM +0200):

> On Mon, Oct 3, 2011 at 3:39 PM, Matthew Weier O'Phinney <[hidden email]>wrote:
> > -- Robert Basic <[hidden email]> wrote
> > (on Sunday, 02 October 2011, 09:15 PM +0200):
> > >
> > > Major work I plan to do:
> > >
> > > 1) Break the current Application::run into Application::run and
> > > Application::dispatch so we can have pre. and post.dispatch events.
> >
> > Not really necessary. You can use priorities for this. :)
> >
> >    $events->attach('dispatch', $callback, 100);  // pre-dispatch
> >    $events->attach('dispatch', $callback, -100); // post-dispatch
> >
> >
> Really? If so, awesome. Thanks for the tip :)

Yes -- we actually use this in the zf-quickstart for setting up
post-dispatch events (they have lower priority). I also use it in my
zf2sandbox repo with both styles -- I use the pre-dispatch (higher
priority) to do things like check for ACLs and/or API keys, and also to
normalize discovered IDs before the controllers execute. I'm primarily
using post-dispatch (low priority) for view-related things.

<snip>

> > > 3) Make the "cli" controllers similar to the current ActionControllers,
> > e.g.
> > > make them locator aware and dispatchable. Also, to have a
> > > (set|get)ConsoleOptions available to all the cli controllers, so any
> > command
> > > line arguments/flags/options can be accessed from inside the action.
> >
> > I'd argue you should go the same route as Zend\Mvc here. Have a wrapper
> > for Console\Getopt that returns a RouteMatch object containing the
> > arguments it captured, and have a special event like MvcEvent that has
> > accessors for it. This would promote re-use of controllers for multiple
> > purposes.
> >
>
> I've seen that, but didn't fully grasp the idea behind it. So, with this the
> same controller could be used from both Http and Cli?

Exactly. And that would argue for approach 3 below, as you would likely
identify both the controller and router via arguments -- allowing you to
simply dispatch them as normal.

<snip>

> > > 3) Each Cli module can have as many controllers and actions as the
> > developer
> > > wants. This way would complicate the whole Console\Getopt things because
> > the
> > > calling would be something like:
> > >
> > >     > php bin/cli.php -c foo -a bar --param value
> > >
> > > and this would call the barAction in the Controller\Foo controller,
> > passing
> > > "param" with "value" (note: the param passing stuff would be available in
> > > any case).
> >
> > Another possibility: try using apt/yum/git/etc. style, and do words:
> >
> >    php bin/cli.php foo bar --extra --params=here
> >
> > I'm not sure how complex this would be to implement, but it would remove
> > some of the extra dash options.
> >
>
> Well, Zend\Tool already works without the dashes, no? Will have a look into
> it.

One thing I recall: Zend\Console\Getopt has a "setArguments()" method,
which allows you to set the string containing all arguments. What this
would allow you to do is parse through $argv until you got to an
argument beginning with a dash. At that point, you'd pass the remaining
arguments to Getopt, and use the others as your "action-style"
arguments.


--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

Wil Moore III
In reply to this post by robertbasic
>
> ...these sub-commands you speak of, what are they?
>

For instance:

./bin/doctrine

Available commands:
  help                         Displays help for a command (?)
  list                         Lists commands
dbal
  :import                      Import SQL file(s) directly to Database.
  :run-sql                     Executes arbitrary SQL directly from the
command line.

"dbal" is a namespace, ":import" is a command (or sub-command) of the "dbal"
namespace. To call it you'd run:

./bin/doctrine dbal:import ...
--
Wil Moore III

Best Practices for Working with Open-Source Developers
http://www.faqs.org/docs/artu/ch19s02.html

Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html

DO NOT TOP-POST and DO trim your replies:
http://linux.sgms-centre.com/misc/netiquette.php#toppost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

robertbasic
On Mon, Oct 3, 2011 at 5:34 PM, Wil Moore III <[hidden email]>wrote:

> ...these sub-commands you speak of, what are they?
>>
>
> For instance:
>
> ./bin/doctrine
>
> Available commands:
>   help                         Displays help for a command (?)
>   list                         Lists commands
> dbal
>   :import                      Import SQL file(s) directly to Database.
>   :run-sql                     Executes arbitrary SQL directly from the
> command line.
>
> "dbal" is a namespace, ":import" is a command (or sub-command) of the
> "dbal" namespace. To call it you'd run:
>
> ./bin/doctrine dbal:import ...
>
>
So basically it's a controller/action call. Think we'll end up having this.
Thanks!

--
~Robert Basic;
http://robertbasic.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

Wil Moore III
>
> So basically it's a controller/action call. Think we'll end up having this.
> Thanks!


Right. The convention is to run an "execute" method (looks like you are
likely to use "dispatch"). Actually, before "execute" is called, another
method "configure" is called. This is where you would set the command name,
help text, and argument/options.

On another note, I'm not sure how practical it is to believe there will be
lots of cases where one will re-use an MVC controller as a CLI controller
as-is. It is more likely that one will be re-using services (and these
patterns are incentive to re-factor toward services anyhow) between MVC
controllers and CLI controllers.
--
Wil Moore III

Best Practices for Working with Open-Source Developers
http://www.faqs.org/docs/artu/ch19s02.html

Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html

DO NOT TOP-POST and DO trim your replies:
http://linux.sgms-centre.com/misc/netiquette.php#toppost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

David Muir-2
On 04/10/11 03:11, Wil Moore III wrote:
> On another note, I'm not sure how practical it is to believe there will be
> lots of cases where one will re-use an MVC controller as a CLI controller
> as-is. It is more likely that one will be re-using services (and these
> patterns are incentive to re-factor toward services anyhow) between MVC
> controllers and CLI controllers.

The MVC pattern is very much applicable to CLI apps. Do you mean, a
controller expecting an HTTP request vs CLI request?

Cheers,
David

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

Wil Moore III
>
> The MVC pattern is very much applicable to CLI apps. Do you mean,
> a controller expecting an HTTP request vs CLI request?
>

Nope...not arguing that at all. I like the MVC pattern for this; however, I
just don't think it is as much a slam-dunk to believe that one will be able
to write a controller for the web application, and re-use it verbatim for
the CLI app. This may work out in some very simple use-cases; however, I've
always found the workflow patterns of a CLI app to be very different from
that of a web app.

That being said...maybe some of those differences are masked with strategic
use of the event manager. I'm interested to see this play out actually :)
--
Wil Moore III

Best Practices for Working with Open-Source Developers
http://www.faqs.org/docs/artu/ch19s02.html

Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html

DO NOT TOP-POST and DO trim your replies:
http://linux.sgms-centre.com/misc/netiquette.php#toppost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

robertbasic
In reply to this post by Wil Moore III
On Mon, Oct 3, 2011 at 6:11 PM, Wil Moore III <[hidden email]>wrote:

> So basically it's a controller/action call. Think we'll end up having this.
>> Thanks!
>
>
> Right. The convention is to run an "execute" method (looks like you are
> likely to use "dispatch"). Actually, before "execute" is called, another
> method "configure" is called. This is where you would set the command name,
> help text, and argument/options.
>
>
This sounds like symfony1.4 tasks. Did the tasks in symfony2 remained the
same? Currently I have this "configure" step in the module.config.php which
then configures Console\Getopt in the Bootstrap. I kinda like that approach,
but will see if it can stay that way.


> On another note, I'm not sure how practical it is to believe there will be
> lots of cases where one will re-use an MVC controller as a CLI controller
> as-is. It is more likely that one will be re-using services (and these
> patterns are incentive to re-factor toward services anyhow) between MVC
> controllers and CLI controllers.
>
>
+1

In ZF1 I actually "stole" a nice little approach from Pádraic Brady (
https://github.com/padraic/ZFPlanet) where he created a Request_Cli to
ensure that the CronController can be accessed *only* from the cli.

But then, if this can be made in such way that the controllers can be
reused, why not? :)

--
~Robert Basic;
http://robertbasic.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

Wil Moore III
>
> But then, if this can be made in such way that the controllers can be
> reused, why not? :)


Agreed.
--
Wil Moore III

Best Practices for Working with Open-Source Developers
http://www.faqs.org/docs/artu/ch19s02.html

Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html

DO NOT TOP-POST and DO trim your replies:
http://linux.sgms-centre.com/misc/netiquette.php#toppost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

robertbasic
In reply to this post by weierophinney
On Mon, Oct 3, 2011 at 4:56 PM, Matthew Weier O'Phinney <[hidden email]>wrote:

>
> Yes -- we actually use this in the zf-quickstart for setting up
> post-dispatch events (they have lower priority). I also use it in my
> zf2sandbox repo with both styles -- I use the pre-dispatch (higher
> priority) to do things like check for ACLs and/or API keys, and also to
> normalize discovered IDs before the controllers execute. I'm primarily
> using post-dispatch (low priority) for view-related things.
>
>
I really did miss out on some nice changes in the past few days/weeks. Thank
you for the tips :)


> Exactly. And that would argue for approach 3 below, as you would likely
> identify both the controller and router via arguments -- allowing you to
> simply dispatch them as normal.
>
>
The more I think about it, the more I see that the 3rd approach would be the
best in the long run; the most flexible, the most usable. Guess I'll be
going that way then :)

One thing I recall: Zend\Console\Getopt has a "setArguments()" method,
> which allows you to set the string containing all arguments. What this
> would allow you to do is parse through $argv until you got to an
> argument beginning with a dash. At that point, you'd pass the remaining
> arguments to Getopt, and use the others as your "action-style"
> arguments.
>
>
Actually this is the first time I'm using the Console\Getopt component. I
wanted to avoid the scenario where I need to parse through $argv, leaving
that to Getopt and that's why I went the -- way. Will dig around Zend\Tool
and Getopt more.

--
~Robert Basic;
http://robertbasic.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

David Muir-2
In reply to this post by Wil Moore III
On 04/10/11 14:37, Wil Moore III wrote:

>
>     The MVC pattern is very much applicable to CLI apps. Do you mean,
>     a controller expecting an HTTP request vs CLI request?
>
>
> Nope...not arguing that at all. I like the MVC pattern for this;
> however, I just don't think it is as much a slam-dunk to believe that
> one will be able to write a controller for the web application, and
> re-use it verbatim for the CLI app. This may work out in some very
> simple use-cases; however, I've always found the workflow patterns of
> a CLI app to be very different from that of a web app.
>
> That being said...maybe some of those differences are masked with
> strategic use of the event manager. I'm interested to see this play
> out actually :)

Ah, yup. I see your point. Almost every single controller I have touches
GET or POST variables, which don't make sense in a CLI app. A controller
action that is console aware would need to know it has to get its
parameters from getConsoleOptions() rather than query(), post(), etc,
which can quickly get messy if not done well.

Are CLI controllers typically handled completely separately from the web
stack in other frameworks?

Cheers,
David
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

Artur Bodera
MVC is model-view-controller. It does not impose or enforce access
method or protocol. Action controllers work on parameters and should
return parameter bags (or some other abstract result) - they should
not "decorate" the data, encode it to any particular format or style.

A good MVC framework with proper separation allows for Action
controllers to do their job and be able to handle any parameters
regardless of their source.

The obvious benefit from that for the dev, is the flexibility. You
could write your Action once, and then use it in Cli, http, in a
background worker (queue), json-rpc and flash messaging at the same
time. The contextswitch plugin in zf1 attempted some of that, but it
could not work around architectural deficiencies of zf1 MVC.

I think it's a good moment in time to do just that for zf2. Of course
there are some differences in how a http workflow is handled as
compared to RPC or Cli, but that is not Controller's job to handle but
mvc's.

If we reached that level of separation of concerns and flexibility,
the Zend_Tool2 idea will be obsolete - we'll just write a bunch of
Action controllers to handle those tasks. Added benefit: we'll
instantly have those methods available for http/Ajax access, which
means easier to implement ZF2 installation/configuration/admin script
:)


A.

On 4 paź 2011, at 06:50, David Muir <[hidden email]> wrote:

> On 04/10/11 14:37, Wil Moore III wrote:
>>
>>    The MVC pattern is very much applicable to CLI apps. Do you mean,
>>    a controller expecting an HTTP request vs CLI request?
>>
>>
>> Nope...not arguing that at all. I like the MVC pattern for this;
>> however, I just don't think it is as much a slam-dunk to believe that
>> one will be able to write a controller for the web application, and
>> re-use it verbatim for the CLI app. This may work out in some very
>> simple use-cases; however, I've always found the workflow patterns of
>> a CLI app to be very different from that of a web app.
>>
>> That being said...maybe some of those differences are masked with
>> strategic use of the event manager. I'm interested to see this play
>> out actually :)
>
> Ah, yup. I see your point. Almost every single controller I have touches
> GET or POST variables, which don't make sense in a CLI app. A controller
> action that is console aware would need to know it has to get its
> parameters from getConsoleOptions() rather than query(), post(), etc,
> which can quickly get messy if not done well.
>
> Are CLI controllers typically handled completely separately from the web
> stack in other frameworks?
>
> Cheers,
> David

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

Wil Moore III
>
> A good MVC framework with proper separation allows for Action controllers
> to do their job and be able to handle any parameters regardless of their
> source.
>

I'm all for it if done without sacrificing flexibility.
--
Wil Moore III

Best Practices for Working with Open-Source Developers
http://www.faqs.org/docs/artu/ch19s02.html

Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html

DO NOT TOP-POST and DO trim your replies:
http://linux.sgms-centre.com/misc/netiquette.php#toppost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: A ZF2 Cli module

weierophinney
Administrator
In reply to this post by Artur Bodera
-- Artur Bodera <[hidden email]> wrote
(on Tuesday, 04 October 2011, 07:57 AM +0200):

> MVC is model-view-controller. It does not impose or enforce access
> method or protocol. Action controllers work on parameters and should
> return parameter bags (or some other abstract result) - they should
> not "decorate" the data, encode it to any particular format or style.
>
> A good MVC framework with proper separation allows for Action
> controllers to do their job and be able to handle any parameters
> regardless of their source.
>
> The obvious benefit from that for the dev, is the flexibility. You
> could write your Action once, and then use it in Cli, http, in a
> background worker (queue), json-rpc and flash messaging at the same
> time. The contextswitch plugin in zf1 attempted some of that, but it
> could not work around architectural deficiencies of zf1 MVC.
>
> I think it's a good moment in time to do just that for zf2. Of course
> there are some differences in how a http workflow is handled as
> compared to RPC or Cli, but that is not Controller's job to handle but
> mvc's.

The problem, however, is that to do due diligence from a security
standpoint in a web application, you _must_ be explicit about the source
of the parameters you use. There are well-known problems with using
$_REQUEST, and any seasoned security expert will steer you well clear of
it.

In ZF1, the Request object performed something similar to $_REQUEST with
its getParam() method. I've actually been advocating _NOT_ using this
(nor the proxy, _getParam(), in Zend_Controller_Action) for some time,
due to the security implications.

Good webdev then implies that you pull from POST or the query string
directly.

As such, there _will_ be cases where we simply cannot re-use
functionality.

Now, on the other hand, routing gives us a little flexibility, and this
is why I was steering Robert to have his CLI router return a RouteMatch
object. If an action method then is only pulling from the RouteMatch, we
can be somewhat assured of the origin, and make it agnostic. Again,
however, this will not work if an action also is making the assumption
that it needs to get input from a form of some sort, as you'll need to
specify the exact source of that input.

> If we reached that level of separation of concerns and flexibility,
> the Zend_Tool2 idea will be obsolete - we'll just write a bunch of
> Action controllers to handle those tasks.

I think this can still be achieved. The difference, however, is that
those action controllers will be limited to the parameters they receive
from the router.

> Added benefit: we'll instantly have those methods available for
> http/Ajax access, which means easier to implement ZF2
> installation/configuration/admin script :)

Again, see my notes above.


> On 4 paź 2011, at 06:50, David Muir <[hidden email]> wrote:
>
> > On 04/10/11 14:37, Wil Moore III wrote:
> >>
> >>    The MVC pattern is very much applicable to CLI apps. Do you mean,
> >>    a controller expecting an HTTP request vs CLI request?
> >>
> >>
> >> Nope...not arguing that at all. I like the MVC pattern for this;
> >> however, I just don't think it is as much a slam-dunk to believe that
> >> one will be able to write a controller for the web application, and
> >> re-use it verbatim for the CLI app. This may work out in some very
> >> simple use-cases; however, I've always found the workflow patterns of
> >> a CLI app to be very different from that of a web app.
> >>
> >> That being said...maybe some of those differences are masked with
> >> strategic use of the event manager. I'm interested to see this play
> >> out actually :)
> >
> > Ah, yup. I see your point. Almost every single controller I have touches
> > GET or POST variables, which don't make sense in a CLI app. A controller
> > action that is console aware would need to know it has to get its
> > parameters from getConsoleOptions() rather than query(), post(), etc,
> > which can quickly get messy if not done well.
> >
> > Are CLI controllers typically handled completely separately from the web
> > stack in other frameworks?
> >
> > Cheers,
> > David
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


12
Loading...