[Catalyst] CatalystX::CRUD::Controller::RHTMLO: related database tables and nested forms

[Peter Karman]

Adam Mackler wrote on 01/13/2010 09:33 AM:
> Thanks for your quick reply.  Forgive me for re-asking, but since each
> decision I make results in an investment of much time, a moment now
> confirming my understanding could save me much backtracking later.
> 
> Am I correct in paraphrasing you here: when using Rose::DBx::Garden
> with Catalyst, the only way to construct a user webpage containing a
> form that is "connected" with (i.e., performs CRUD operations on)
> multiple, related database tables is with major surgery of the perl
> modules as installed from CPAN?  The only way to do it without more
> programming than (you accurately assess) I desire to do is to simply
> accept that the data for separate tables must be entered on separate
> forms on separate webpages?  Is that accurate?

That's pretty accurate. However, let me clarify some terms to make sure
we're talking about the same thing:

* Rose::DBx::Garden creates scaffolding only. It creates RDBO-based and
RHTMLO-based classes, which assume 1 table == 1 form. There is no
generation of code to handle subforms, though as you experiences, it's
relatively easy to add those later. RDG just tries to remove the tedium
of creating all the RHTMLO classes just like RDBO::Loader does for RDBO
classes.

* Rose::DBx::Garden::Catalyst extends RDG to create Catalyst Controller
and Model scaffolding. The assumption is 1 table == 1 form == 1
controller class == 1 model class. The base Controller, Model and View
classes in RDGC are simple subclasses of CatalystX::CRUD::YUI.

* CatalystX::CRUD::YUI is a whole Catalyst application. CXCY has all the
.js and .tt files included so you get the UI for free, which you can
extend and customize by overriding .tt files in your local app's
root/crud directory. The limitations you are encountering are with the
View (the .tt and .js), not anything with CatalystX::CRUD or the CXCY
.pm files in particular I don't think. The assumption of 1 table == 1
form == 1 controller == 1 model is baked into the View in
CatalystX::CRUD::YUI. You don't have to use that View; you can write others.

* CatalystX::CRUD is the underlying framework. Again, it assumes 1
controller == 1 table == 1 form. CXC is intentionally agnostic with
regard to View. CatalystX::CRUD::YUI is just one implementation that
works out of the box with the simplest of assumptions about 1
controller, 1 table, etc.

> 
> If so, some questions and thoughts:
> 
> A question: would this limitation go away if I were still using the
> Rose DB and Form objects, but not working from a plant()ed
> application? The reason I ask is that I have seen a solution, but it
> doesn't work with CatalystX::CRUD::Controller.  I don't want to
> dismiss good with bad; in this case Rose Forms may be okay for me but
> maybe the CatalystX::CRUD::Controller is a problem?
> 

The CatalystX::CRUD::Controller is not the problem, I don't think. I
think the problem is presentation (View). See above.

<snip>

> In any event, I'll repeat (perhaps unnecessarily) that I'm really not
> a programmer, and maybe I've bit off more than I can chew.  Maybe a
> simpler (or at least more-used-and-thus-more-documented) solution like
> FormFu would be a better choice for my purposes?  Thing is, I just
> can't get over how pimped-out this magically-planted app is.  I'd hate
> to lose such features if I don't have to.

You might look at Catalyst::Plugin::AutoCRUD. It's designed for people
who don't want to extend or modify their code very much, and is very
nice imo.

> 
> One thing I haven't mentioned: my database that I'm wanting to build
> this app on top of has about forty tables, all related to each other.
> I'm concerned that a "simpler" solution such as FormFu might start
> breaking down as the complexity of my app grows.
> 
> I'm trying to do this with RHTMLO partly because I thought it might be
> the best choice for me, but also just because I've found that the only
> way to be sure of which solution is the right one is by trying each.
> As always, I'm ready to learn why I'm doing things the wrong way, and
> what some other possible right ways might be.
> 

RHTMLO is really nice for programmers who think like John. I happen to
be one. If you don't want to program, then something that Just Works is
probably a better choice.

> 
> P.S. Peter: on behalf of all people who ever wished there were more
> documentation, thank you for encouraging others to create such
> documentation.  Once I feel competent enough to, I look to make my own
> documentary contribution to this realm...but that's a ways off yet.
> 

heh. I'm just lazy when it comes to documentation. Perhaps it is
backlash from my time as a technical writer. :)


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