[cgiapp] Pre-Announcement and Help Request

[Ron Savage]

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
ron at savage.net.au
http://savage.net.au/index.html