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 [EMAIL PROTECTED] http://savage.net.au/index.html ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################