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/ . [EMAIL PROTECTED]
##### 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/ ##
## ##
################################################################
