Re: [cgiapp] Re: Writing the CGI::Application book

[Richard Dice <suppressed>]

Regarding my suggestion that Class::DBI is preferable to raw SQL & DBI 
in a large scale complicated web app project, Sam said:

> I honestly couldn't disagree more. [deletia]

Class::DBI could indeed be underpowered to handle the kind of 
complicated cases that you describe.  [ Could Tangram be the answer 
there, though?  It has much more evolved object relationship mapping 
semantics. ]  [ However, did you know that you can directly write 
arbitrary SQL, execute and object-wrap the query returns from within 
Class::DBI?  Maybe this would allay your concerns with it. ]

My experience with SQL & DBI is that it quickly becomes unwieldly.  I 
guess my question is, what kind of "SQL/DBI helper" techniques are you 
using to reign in the unwieldly-ness?

There are a number of CPAN modules that typify each technique.  [ E.g. 
SQL::Snippet for collecting all SQL and sticking it in out-of-the-way 
places, DBIx::Recordset for object wrapping of SQL queries for 
managability. ]

If you use these kinds of available tools, and use them well, then I can 
believe that a similar level of convenience & maintainability to (e.g.) 
Class::DBI could be achieved, while still keeping ahold of the direct 
access to "bare metal" SQL power.

However, "naive" use of DBI w/embedded SQL with the standard kind of 
prepare/execute/fetchrow loop seems like flaming death to me.

Which kind of approach were you using?  Or did you use a "third way"?

> > HTML::Template is a good candidate for the "view" (but not the only
> > candidate!).  [ "print" statements and here-documents are *NOT* good
> > candidates. ]
>
> Now this we can agree on!

Indeed. :-)

Cheers,
Richard


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
             http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed