[cgiapp] Pre-Announcement and Help Request

[Ron Savage]

Hi Peter

On Thu, 2008-04-17 at 19:53 -0500, Peter Karman wrote:
> 
> Ron Savage wrote on 4/17/08 6:01 PM:
> 
> > 
> > I haven't decided if the user's paging should trigger AJAX-style
> > requesting of more data, or if I should use a session to pass
> > 'where-was-I-up-to' between Rose and the client.
> > 
> 
> I just put params in the URI to indicate the result set. The _page, _offset and 
> _page_size params are all reserved for that in CatalystX::CRUD.

Right. I'll do that I guess. I'm just not yet at that stage.

> >> I'm actually at work on refactoring RDGC to install a base set of .pm and .tt files in
> >> @INC at install time, rather than generating all that code at run time. I think that will
> > 
> > I generate all code before run-time.
> > 
> 
> sorry, I should have been more clear. RDGC generates all the code used by the 
> Catalyst app ahead of time. You only run RDGC once, to create all the necessary 

Yep. I've used it to generate an app. What I couldn't understand is why
it was so slow to run, even after I tried deleting the '-debug' option,
and switching from the test HTTP server to Apache. I thought it
(Catalyst?) may have been generating vast amounts of code at run time. I
could uderstand the -debug option being slow, but not all alternatives.
This was another motivation for my current work :-).

> files. What I am planning to do in the next release is actually generate *less* 
> code and instead RDGC will ship with more .pm classes that will be subclassed by 
> the generated code. So the output of RDGC will be less when you run it, but 
> RDGC-based classes will actually be used by the running Catalyst app.

Right. Sounds good.

> E.g., instead of generating a MyApp::Base::Controller::RHTMLO file with a lot of 
> code in it, RDGC will generate a stub like this:
> 
>   package MyApp::Base::Controller::RHTMLO;
>   use strict;
>   use base qw( Rose::DBx::Garden::Catalyst::Controller );
>   1;
> 
> There's a tradeoff there, because now Rose::DBx::Garden::Catalyst must be 
> installed on machines where MyApp is deployed. But I think it makes for an 
> easier upgrade path when a new RDGC is released with more features, because you 
> do not have to regenerate any files. Just install from CPAN like any other module.

I generate a distro-like dir structure, so your normal make mechanism
will turn it into a distro KillerApp-1.00.tar.gz, for ease of
installation. It'll have pre-reqs just like a real module :-).

So, yes, thinking in terms of distros rather than just code really
appeals to me.

> >> make it easier to update RDGC later and get new features. I'll be changing the TT
> >> INCLUDE_PATH to look first at the local doc_root and then a the installed .tt file path,
> >> so that you can override the installed .tt behaviour with local files. Like subclassing
> >> your templates. That means that RDGC is changing from a pure code-generator to more of a
> >> turn-key webapp/CRUD solution.
> > 
> > I did see in your code you had a data-only module to ship CSS, JS, etc.
> > I decided to adopt YUI too, but to keep it separate. That way people can
> > upgrade YUI independently of my code, since my config file holds the URL
> > prefix of where YUI's 'build/' dir is installed. Also, it allows me to
> > slowly utilize more and more of the YUI feature-set, not just DataTable.
> > 
> 
> yes, RDGC works the same way. I do not bundle YUI. I have a single .js file that 
> just uses YUI to do some stuff, and then call in the YUI files from the yahoo 
> site using a configurable head.tt file.
> 
> Of note is that the next version of RDGC will have support for YUI 2.5.1, which 
> has a lot of Datatable API changes in it over the previously supported 2.3.1.

Yep. I just downloaded V 2.5.1 myself.

As for the templates, it'd be easy to ship both HTML::Template and TT
versions of any used at run time. I'll keep that in mind.
-- 
Ron Savage
ron at savage.net.au
http://savage.net.au/index.html