Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

scripting frameworks - a cursory glance

by metaperl (Curate)
on Mar 17, 2010 at 21:55 UTC ( #829276=perlmeditation: print w/ replies, xml ) Need Help??

I was looking to write a script that required quite a bit of modularity and separation of generic concerns from the scripts concerns. I have found 3 such frameworks (briefly discussed below) but would be glad to hear of others

CLI::Framework

CLI::Framework seems to be the most useable of the 3. It has good docs. It comes with two working samples, one simple example and one much more complicated. The complicated example shows how to maintain state in an application and share that state between commands. One issue is that the object-oriented access to that state in the command is via $self->$slot not $self->app->$slot thus potentially creating conflicts between application slots and command slots.

App::Cmd

App::Cmd is by the prolific and well known Ricardo Signes. Like CLI::Framework, it support subcommands. It does not come with complete samples. But the nice thing is you can find Ricardo on irc.perl.org almost anytime of the day or night. Both App::Cmd and CLI::Framework delegate option processing to Getopt::Long::Descriptive.

One key difference between the two is that you manually map application command names to modules in CLI::Framework. App::Cmd automatically loads all modules under the namespace of your application module.

Why is App::Cmd not quite as good as CLI::Framework

It's scary to pick someone over Ricardo, but the lack of working examples, along with the lack of pre-packaged common commands make CLI::Framework a bit more attractive.

On the other hand, if you have a lot of commands to write and dont like updating a central dispatch table, then the decentralized control and coordination of App::Cmd might be just the ticket for you.

App::Framework

App::Framework is interesting. The one thing it seems to lack is any mechanism for commands. In other words, it aimed to make applications more scaleable, but it has no support for application command (and subcommand) dispatch. Both of the other frameworks have support for subcommands, allowing for options to be specified both for the application as well as the (sub)commands.

But only CLI::Framework provides fully working examples of it.

Comment on scripting frameworks - a cursory glance
Select or Download Code
Re: scripting frameworks - a cursory glance
by Anonymous Monk on Mar 18, 2010 at 04:59 UTC

        Actually App::Cmd::Tutorial does reference subcommands.

        Quoting:
        When a new application instance is created, it loads all of the command classes it can find, looking for modules under the Command namespace under its own name. In the above snippet, for example, YourApp will look for any module with a name starting with YourApp::Command::.

Re: scripting frameworks - a cursory glance
by krazyk (Beadle) on Mar 18, 2010 at 14:37 UTC

    I am Glad you like CLI::Framework (I'm the author). Just a couple of things worth mentioning...

    Those who are interested can see CLI::Framework design goals and features for a concise list of what is offered by "CLIF." This feature list is, in a nutshell, why I created CLIF instead of using another module intended to assist in building command-line applications.

    There are no "conflicts between application slots and command slots." Application objects and command objects can share state using the cache. Commands are aware of the cache, but they are generally unaware of the application (metacommands are an exception). This is by design to encourage decoupling commands from applications. Commands could conceivably be used and reused independently from applications. Your commands will use $self->cmd_method() to call a command method and usually should not directly call app methods. However, when necessary (as in some of the built-in commands), they'll do so using $self->get_app()->app_method(). Thus, command methods are called via command objects and if a particular command is application-aware, it has a get_app() accessor which returns the app object. See the definition of a Metacommand and the POD for Command::Meta.

    Finally, be aware that I'm still standing behind the distribution. It's still relatively young and has some rough edges that I plan to polish. I'm doing this "on the side" and primarily for myself, but if anyone is using it and has any requests or suggestions, let me know. I'd still like to make it a nice solution for everyone's needs!

    One additional module to add to your list: App::CLI. Maybe I'm biased, so I'll let you draw your own conclusions.

      There are no "conflicts between application slots and command slots." Application objects and command objects can share state using the cache.
      Yes, but the cache is a component of the application object. And the command object should access application object components via  $self->app->cache not the current way $self->cache
        You are mistaken. The cache object accessible by $self->cache() (where $self is the Command) is the same cache used by the application (and your suggested $self->app->cache() would, if it were supported, do exactly the same thing -- access the cache shared by both the Application and the Command). Once again, the cache is shared state. It is not a "component" of the Application, but rather an instance variable (a reference to the Cache object) kept in both Application and Command.

        It would make no sense for "application object components" to be accessed via the cache (regardless of the syntax used to access the cache). The cache stores whatever a user wants to share (like a logging or a database object), not internal CLI::Framework data.

        If you're reading the code, then yes, the Cache class happens to be implemented inside the Application module (mainly because the existing Cache class is trivially simple and may later be replaced by a more powerful caching system like CHI; I decided it is unworthy of its own module at this stage). But that doesn't make it a "component" of the Application class.

Re: scripting frameworks - a cursory glance
by TGI (Vicar) on Mar 22, 2010 at 21:08 UTC
the App::Cmd advantage is moose leverage
by metaperl (Curate) on Mar 23, 2010 at 17:37 UTC
more cli frameworks...
by metaperl (Curate) on Mar 24, 2010 at 20:19 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://829276]
Approved by ww
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (7)
As of 2014-08-22 09:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (153 votes), past polls