RE: [cgiapp] ANNOUNCE BETA: CGI::Application::Template 0.01

["Jesse Erlbaum" <suppressed>]

Hi Mark --

First off, thanks for the feedback!  I'm very interested in getting some
ideas before I put this module out to the world.


> I would find this somewhat useful. I think the interface I
> would like best would either be an "interview" on the command 
> line, or a web form that I just fill in.

That was one of my first ideas.  I went with an API instead because I
thought those other things could be built upon this system.  Someone
could easily write a Term::ReadLine based script to pose questions to
the user.

I would welcome any code contributions!  I imagine that this might be
implemented similarly to CPAN's shell() function:

  $ perl -MCGI::Application::Template -e shell


> In some ways it feels inefficient because some things are
> declared only once, so there's not time saved in automation 
> there. Some detail points:
> 
> - I was surprised you didn't use the new arrayref method of declaring
>   run modes.

I did, and then I switched back for two reasons:  First, I didn't know
if the user would be using CGI-App 3.0.  Second, I wanted to make the
output module more easy to adapt, if desired.  Perhaps I'll change it
back.


> - It would be nice to combine these common three rows of output code
>   into a single function:
> 
>    open(OUTPUT, ">WidgetBrowser.pm") || die($!);
>    print OUTPUT $cat->output_app_module();
>    close(OUTPUT);

I thought about that, too.  In the end, I chose not to write the file
because I didn't want to prevent someone from using this module in a
different way which didn't involve creating a file.

Perhaps this can be part of a the function of a shell() interface?


> It seems like the most useful benefit here is creating the
> stubs of the functions. Currently I handle this tedium with 
> abbreviations defined in my text editor, which makes this 
> fast, but also handles exceptions easier.
> 
> Currently I address this problemspace by having a "template
> project", which I duplicate and run a couple of regular 
> expressions over by hand to get it ready. This doesn't addres 
> the stub functions, though.

Yes -- this is the major motivation for me, too.  The run-mode method
stubs which are created are really pretty much what I like to start with
when I write a new application:

    sub run_mode_method {
        my $self = shift;

        my $q = $self->query();
        my $dbh = $self->param('DBH');

        return $self->dump_html();
    }


I've also included stubs for POD documentation in each module.  In the
stub POD I am "advising" on what I think should be included in any
CGI-App module documentation.  Any thoughts?


FWIW, this module was inspired by two other systems:

  1. h2xs  - A good starting point for any Perl module.  I wanted to
create something which would be a good starting point for a CGI-App
module.

  2. Microsoft's visual studio products  - Say what you want about
Microsoft, but their visual studio products are quite mature.  I like
the way they automatically create a program stub when you begin.  I
have, for years, imagined something which provides the same function for
CGI-App.


Thanks for your feedback, Mark!

-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