Hi Peter On Thu, 2008-04-17 at 08:26 -0500, Peter Karman wrote: > > On 04/17/2008 03:15 AM, Ron Savage wrote: > > Hi Folks > > > > I'll soon release CGI::Application::Bouquet, which uses Rose::* > > (including Rose::DBx::Garden), CGI::Application and > > CGI::Application::Dispatch. > > > > A Bouquet of Roses, get it :-))? > > > > And yes, it's a CGI::Application version of Rose::DBx::Garden::Catalyst. > > > > sounds cool.
Thanx. Your code was a significant impetus to me. I'll be crediting your work in the docs-to-be (patches welcome - Hahahahahahaha). > > As yet it treats the database as read-only, so my code is a search > > engine tailored to a specific database, but has no update facility. > > > > any particular reason you haven't gone the whole way to a complete CRUD > solution? You > might look at CatalystX::CRUD for how I've been doing that in Catalyst-land. Reason? Yes - $effort x $compexity. Also, I'm a real beginner with Rose, and wish to use this work as a vehicle to train myself in its intricacies. I only work part-time (due to choice), so time itself it not short. Practically, I simply wanted to get something running before adding updating, which I perceive to be rather more difficult. > I'm interested in your thoughts on paging. There are 2 paging modes in > > use: > > (1) Using Rose::DB::Object::Manager > > (2) Using YAHOO.widget.Paginator (see http://developer.yahoo.com/yui/ ) > > #2 is really only useful if you use the YUI Datatable. That's what the > templates in RDGC > use. They still do server-side paging though, so RDGC actually uses both. I > use > Data::Pageset in CatalystX::CRUD. Look at [1] for the CatalystX::CRUD > implementation. I am already using both. I did say 'in use', but thought after posting I should have emphasized that. 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'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. > 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. > I mention that because a lot of the magic in RDGC is in the .tt and YUI code, > and it might > be interesting to see if we could share some of that .tt code between the two > projects. > Assuming of course that you have any interest in adding the full CRUD > features to your > project. Yes, I do want CRUD one day. I hadn't said, but /all/ code I generate uses HTML::Template-style templates, not the way you've been doing it. Of course, usually users will have no reason to patch the code, but they can reformat it if desired. As for Template Toolkit, yes I've thought about it a lot over the years, but as always feel it is too complex for this. I do realise it's a very clever package. I guess I'm anti-TT in the same way I'm anti-CGI.pm. I should add I'll be shipping 2 types of templates, one for code generation, and one for run-time web page construction. Eg. the URL prefix of YUI's 'build/' gets jammed into 1 master HTML template at code/template generation time. I don't mind sharing. Perhaps it'll be easier to visualize the similarities when you see my stuff working. Don't forget you're a long way ahead of me on this path. Also, I'll ship an FCGID app with install instructions, for test-running all this (as distinct from running tests). I'd better do a plain CGI script too :-). > [1] > http://search.cpan.org/~karman/CatalystX-CRUD-0.25/lib/CatalystX/CRUD/Model/Utils.pm#make_sql_query(_[_field_names_]_) Yep, I'll be looking at your code again, if only to rip off good ideas... Actually, out of interest, I re-wrote your Rose::DBx::Garden in order to understand it, but have no plans to release that (unfinished) module. It too uses HTML::Template-style templates for code formatting. -- 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/ ## ## ## ################################################################
