[Catalyst] Simple literal Model

Ashley Pond V apv at sedition.com
Sat Feb 26 17:11:36 GMT 2011


On Fri, Feb 25, 2011 at 9:22 PM, John M. Dlugosz <wxju46gefd at snkmail.com> wrote:
>  On 2/25/2011 9:30 AM, Ashley Pond V apv-at-sedition.com |Catalyst/Allow to
> home| wrote:
>>
>> What t0m suggested is perfectly fine but if you want to mimic the DBIC
>> API with a different engine, this example does that (superficially and
>> as a tutorial only): http://sedition.com/a/2739 Log file model–Apache
>> access log. The reason that example makes sense is because the
>> underlying model/data is similar: searchable, sortable rows. If you're
>> trying to shoehorn in something dissimilar, you might be making a
>> mistake.
>>
>> -Ashley
>
> I'm not sure to what extent it is wise or correct.
> The whole point of "models" is that it abstracts the model and I can change
> where the data comes from later, right?  So don't they all have an
> underlying abstract interface regardless of how they are sourced?

Well, models just differ. DOM, relational, even hash and array with
all their similarity need some minor acrobatics if they are to be
treated alike. You can make an API to attempt to unify all the
possible data models but that would create an artificial complexity
much harder to track and work with.

This hits a sore spot for me. I've seen what I take to be a sort of
"purity of MVC" just about kill projects and make them incredibly
painful to work on. The layers are to make work easier, testable,
quicker, delegated, etc, not to achieve some fantasy where the
templates from a Cat app can be plugged into Rails or Django without
modification.

> The examples I've read using DBIC use
>    [% WHILE ( item = list.next) %]
> and I can imagine that in general we don't have efficient random access to
> the rows; in C++ I would characterize this as a "forward iterator" or even
> weaker, if I can't make a copy of the earlier state and go forward a second
> time.
>
> I would have hoped that the TT [% FOREACH %] directive would work here.
>  That seems like the natural means of abstracting the list.  That is, the
> controller can set anything into the stash that FOREACH knows how to handle,
> including a plain Perl array.

The API for that in DBIC+TT would look like [% FOR record IN
list.all() %] or list.search({contraints...},{rows=>max_rows}) or
list.search_related().... etc, etc. The idioms are mostly the same in
TT as plain Perl. "for" can't recursively call an iterator any more
than "while" can unroll a list.



More information about the Catalyst mailing list