RE: [cgiapp] ANNOUNCE: CGI::Application::Generator 1.0

["Jesse Erlbaum" <suppressed>]

Hi All --

> Version 1.0 of CGI::Application::Generator is now available via CPAN!

I've release an initial version of CGI::Application::Generator.  This
does not include most of the (excellent) suggestions which came from our
discussion.  Here is a list of the items I would like to implement in
forthcoming versions:

 * Complete mode_templates() method, to associate specific templates
   with a run-mode.

 * Write shell() method to interview the developer and create a module
   from interactive input.

 * Create an XML DTD and a SAX interface to convert XML to a
   CGI::Application module.

 * Allow arbitrary data to be passed through Generator to the
   underlying HTML::Template file.  Through this mechanism, more
   sophisticated applications might be dynamically created.


I wanted to specifically talk about this fourth idea.  This is in
response to a specific comment by Cees:

> One comment I have on the code it generates.  I personally 
> don't like the fact that the Database connection is made 
> on every call.  I quite often have a mix of pages that may 
> or may not require the database.  I realize that I could 
> easily customize the app_module.tmpl template locally for 
> my own use, but I think it is at least worth bringing up. 
> Personally I would use something simple like the following 
> for database access.

This is both a potential performance issue, and a matter of style.  I do
not claim that my template is right for every situation or company.
Instead of trying to come up with a "one size fits all" output format, I
would like to build in flexibility.  

I think that one way to do so effectively would be to allow a data
structure to be passed into C::A::G, which will be directly passed into
the HTML::Template file on the other side.  This would allow you to
develop a custom template which would be able to configure arbitrarily
sophisticated output.

I would be interested in discussing this with all of you, in order to
devise an interface which will permit sufficient control.  One idea I
have is to provide three configurations for application specification to
control the specification of the "use modules" scope, "run modes" scope,
and package-level scope:

    # Use-modules scope
    $cag->use_modules(qw/My::DBICreds My::Utilities/);
    $cag->use_modules_additional_data(
        My::DBICreds => {import => []},
        My::Utilities => {import => [qw/add_widget delete_widget/]},
    ); 

    # Run-modes scope
    $cag->run_modes(qw/
        list_widgets
        add_widget
        insert_widget
        edit_widget
        update_widget
        delete_widget
    /);
    $cag->run_modes_additional_data(
        list_widgets => {use_dbh => 1},
        insert_widget => {use_dbh => 1},
        update_widget => {use_dbh => 1},
        delete_widget => {use_dbh => 1},
    );

    # Package scope
    $cag->additional_data( add_content_handler => 1 );


What do you all think of this?

TTYL,

-Jesse-


--

  Jesse Erlbaum
  The Erlbaum Group
  suppressed
  Phone: 212-684-6161
  Fax: 212-684-6226




---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed