[cgiapp] Pre-Announcement and Help Request

[Peter Karman]

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.

>> 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 
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.

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.


>> 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.


-- 
Peter Karman  .  http://peknet.com/  .  peter at peknet.com