Cli Prototype

[mattcockayne]

Hi All...

I was having a look at the Cli solution the other day and decided to mock up
a quick prototype. Its rather rough and ready but wanted some opinions as to
the format and structure.

Here are a few bits of my thinking when i was knocking it together.

   1. I was looking to simplify the way the cli worked in comparison to the
   "tool". I took inspiration from symfonys console and the work done by
   RobertBasic
   2. I wanted to decouple parts of the cli to individual parts
   (environment, arguments, output, application, etc) to encourage reuse
   3. The environment component needed to detect the environment and set it
   up if required.
   4. The arguments component would parse the arguments passed from the cli
   and put the into an object that could then be passed around and manipulated
   as required
   5. The output needed to be interchangeable with alternatives if required.
   6. The Application needed to only concentrate on handling all other
   objects and routing to the right module
   7. Module loading needed to utilise current ModuleLoader and the
   Module.php file
   8. I wanted to make the cli work in a modular fashion like the MVC to
   make it easier to extend by following a similar pattern.
   9. The cli has to work universally with common modules for creating
   project structures such as controllers/view/modules/models etc including
   created projects themselves
   10. The cli has allow me to add additional "common" modules.
   I achieved this by cannibalising bits of the the current "Tool" to allow the
   setting of values in a zf.ini file in the current users home to. This allows
   me to add third party modules easily.
   11. Routing needed to be simple using no more that two arguments. I have
   mapped these with a pattern of ./zf2.sh module method [arg1 [arg2 [...]]]
   12. the cli needs to allow double or single hyphen options (i.e.
   --verbose|-v) which can then be passed to the application/modules for
   handling
   13. Module loading needed to utilise the Module.php file.
   14. Because routing is very simplified a separate interface was needed.
   This was created in the Cli.php file. The Cli file can then proxy to
   Controllers if needed or can provide separate standalone methods
   15. The Cli must contain the methods help and getCommands. help will
   produce details help for a module (i.e. `./zf2.sh project help` will give
   info on what the project module does) the getCommands method will return an
   array of data that will give a command & arguments list (i.e. `./zf2.sh
   --help`)


So far what i have works well I have it working with "common" modules both
within the library and externally as well as modules from wiithin a project
(providing you are at the project root).

here are a couple of caveats that i know of (please remember that its an
EXTREMELY rough mock up of an idea so im probably missing tons of "features"
and common sense bits)

   1. The prototype does not use DI at the moment. I need to add that.
   2. There is no error handling in place at the moment
   3. All of the components need lots of work with vast room for improvement
   4. for the sake of speed I put some common modules in the
   Zend/Cli/Modules folder... These will not remain like this. they are just
   there to get a quick prototype together
   5. I have only testing this on a linux box. (havent used windows in that
   long i dont have a copy to test on)
   6. I have only put together two modules "project" and "module" are these
   are as bare bones as you get and dont do much more than spit out some
   pointless help and commands

I suspect that there are a million and one ways to skin this cat. please
bear in mind that this is just my interpretation. If its not your cup of tea
and you think its totally the wrong direction then please be constructive in
your criticism, or even better put together a prototype of your own for us
to review.


heres the link to my repo...

https://github.com/zucchi/zf2-1/tree/prototype/cli

[robertbasic]

Hi Matt!

I browsed through your code, you'll find my thoughts bellow :)

On Thu, Oct 20, 2011 at 7:39 PM, Matt Cockayne <[hidden email]> wrote:

> Hi All...
>
> I was having a look at the Cli solution the other day and decided to mock
> up
> a quick prototype. Its rather rough and ready but wanted some opinions as
> to
> the format and structure.
>
> Here are a few bits of my thinking when i was knocking it together.
>
>   1. I was looking to simplify the way the cli worked in comparison to the
>   "tool". I took inspiration from symfonys console and the work done by
>   RobertBasic
>   2. I wanted to decouple parts of the cli to individual parts
>   (environment, arguments, output, application, etc) to encourage reuse
>

My plan too, to have some "Output" object implementing the
Zend\Stdlib\MessageDescription interface and "Arguments" implementing the
Zend\Stdlib\ParametersDescription.


>   3. The environment component needed to detect the environment and set it
>   up if required.
>

Hm, never thought about the environment, good catch.


>   4. The arguments component would parse the arguments passed from the cli
>   and put the into an object that could then be passed around and
> manipulated
>   as required
>

That's Getopt, right?


>   5. The output needed to be interchangeable with alternatives if required.
>

I've seen it in the Environment class, Output has info() and similar
methods. Maybe we could make these as "view helpers"? Also I plan to move
the output decorators from Zend\Tool to Zend\Console\Output, I'll write more
about this in a separate thread.


>   6. The Application needed to only concentrate on handling all other
>   objects and routing to the right module
>

I agree. Do we need events here, like predispatch, postdispatch...? I don't
think so, having cli controller plugins seems a bit silly :D


>   7. Module loading needed to utilise current ModuleLoader and the
>   Module.php file
>

+1


>   8. I wanted to make the cli work in a modular fashion like the MVC to
>   make it easier to extend by following a similar pattern.
>

+1


>   9. The cli has to work universally with common modules for creating
>   project structures such as controllers/view/modules/models etc including
>   created projects themselves
>

The cli, or a tool/module built with the cli? I'm more for the latter.


>   10. The cli has allow me to add additional "common" modules.
>   I achieved this by cannibalising bits of the the current "Tool" to allow
> the
>   setting of values in a zf.ini file in the current users home to. This
> allows
>   me to add third party modules easily.
>

Again, I'm in for a tool built with cli.


>   11. Routing needed to be simple using no more that two arguments. I have
>   mapped these with a pattern of ./zf2.sh module method [arg1 [arg2 [...]]]
>

./zf2.sh module controller action arg1 ... argn

where module, controller and action are all required parameters, no default
ones. The remaining arguments would be in Cli\Arguments which implemets
ParametersDescription. I have a concern about this tho, but will take that
to a separate thread.

  12. the cli needs to allow double or single hyphen options (i.e.
>   --verbose|-v) which can then be passed to the application/modules for
>   handling
>

+1, but see above.


>   13. Module loading needed to utilise the Module.php file.
>

See 7. :P


>   14. Because routing is very simplified a separate interface was needed.
>   This was created in the Cli.php file. The Cli file can then proxy to
>   Controllers if needed or can provide separate standalone methods
>

I need to have a look how did Ben make the Routing, but I hope there's
something we can (re)use/steal ideas from.


>   15. The Cli must contain the methods help and getCommands. help will
>   produce details help for a module (i.e. `./zf2.sh project help` will give
>   info on what the project module does) the getCommands method will return
> an
>   array of data that will give a command & arguments list (i.e. `./zf2.sh
>   --help`)
>
>
Actually, Getopt has the getUsage() method which composes a usage printout,
based on the registered commands. We should use this, IMHO. Also, Getopt has
a few @todo's, namely adding "header/footer" content to this getUsage()
method and a more general help method. I plan to work on these too, to
improve Getopt.

>
> So far what i have works well I have it working with "common" modules both
> within the library and externally as well as modules from wiithin a project
> (providing you are at the project root).
>
> here are a couple of caveats that i know of (please remember that its an
> EXTREMELY rough mock up of an idea so im probably missing tons of
> "features"
> and common sense bits)
>
>   1. The prototype does not use DI at the moment. I need to add that.
>   2. There is no error handling in place at the moment
>

As for the error handling, I just print out the Getopt::getUsage stuff.


>   3. All of the components need lots of work with vast room for improvement
>   4. for the sake of speed I put some common modules in the
>   Zend/Cli/Modules folder... These will not remain like this. they are just
>   there to get a quick prototype together
>   5. I have only testing this on a linux box. (havent used windows in that
>   long i dont have a copy to test on)
>

Oh. Windows. Awkward.

>   6. I have only put together two modules "project" and "module" are these
>   are as bare bones as you get and dont do much more than spit out some
>   pointless help and commands
>
> I suspect that there are a million and one ways to skin this cat. please
> bear in mind that this is just my interpretation. If its not your cup of
> tea
> and you think its totally the wrong direction then please be constructive
> in
> your criticism, or even better put together a prototype of your own for us
> to review.
>
>
> heres the link to my repo...
>
> https://github.com/zucchi/zf2-1/tree/prototype/cli
>

--
~Robert Basic;
http://robertbasic.com/