[Catalyst] Program the logic

[Marcello Romani]

Marcello Romani ha scritto:
> Brandon Black ha scritto:
>> On 6/29/06, Nilson Santos Figueiredo Junior <acid06 at gmail.com> wrote:
>>> On 6/29/06, Brandon Black <blblack at gmail.com> wrote:
>>>> If you find yourself putting code in your View templates that isn't
>>>> directly related to rendering this specific flavour of output, it
>>>> probably needs to be moved to the Controller.  Good code in views:
>>>> iterating an arrayref to generate a <ul> list, walking a data
>>>> structure to generate a <table>, or walking a data structure to
>>>> generate a graph image.
>>> I've found myself building somewhat "fat" views lately. Mostly, I've
>>> done it when trying to build generic "widget" thingies that might
>>> appear in different pages. By "fat" I mean resultset-manipulating
>>> views, but usually the manipulations are restricted only to the
>>> view-related aspect of them, though. This means stuff like ordering
>>> the resultset by some column (using order_by). I'm usually in doubt if
>>> this is indeed a good practice or if it should be done another way,
>>> but it sure makes things easier.
>>>
>> I think its fine to have the controller generate a resultset, and have
>> the view directly apply ordering and/or paging to the resultset before
>> generating HTML from it.  But then again, I also find that approach a
>> bit difficult and limiting.
>>
>> The approach I'm attempting lately (and I haven't gotten it all
>> working right yet...) is to make Controller base-classes that
>> implement generic concepts for things like paging and sorting tables
>> of data (complete with handling form args like ?page=3&count=50 or
>> ?sortby=foo:desc silently for the controller), which makes it
>> effortless for the controller to apply those sorts of things to the
>> resultset before its sent to the view.  These bits of controller
>> functionality are of course View-agnostic.
>>
>> They (the base controllers implementing these features) basically boil
>> down to: Check for some standardized GET form parameters, provide some
>> data to the controller in the form of a paging object or some DBIC
>> sorting hashref stuff, and also directly set stash variables for the
>> views to see, regarding paging and sorting.  There are template
>> includes that go along with these meta controller actions (displaying
>> the << < 1 2 3 > >> paging clickies and whatnot, based on those stash
>> vars...).
>>
>> Ultimately if I can ever get these concepts sufficiently genericized
>> and bulletproof (or if anyone else does before me), it'd be a good
>> idea to throw some out on CPAN as Catalyst::Controller::PageSort or
>> something of the sort.
>>
>> -- Brandon
> 
> I've put together a solution that is inspired by the those same 
> concepts. Instead of building controller base-classes, I've written a 
> Catalyst::Controller::CRUD class which has only private methods, like 
> setup_order(), setup_pager(), etc.
> Those methods are called by the crud controller managing a particular 
> type of objects (i.e. a table or view) using forward(). Maybe it's 
> clearer with an example:
> 
> in MyApp::Controller::Products:
> 
> sub list : Local {
>      my ($self, $c) = @_;
>      $c->forward('/crud/setup_order');   # if one wants column sorting 
> functionality
>      $c->forward('/crud/setup_pager');   # if one wants pager support
>      $c->forward('/crud/list');          # finally display the template
> }
> 
> The logic to handle ordering parameters (which are named for example 
> Xorder, Xo2, etc. to lessen the probability of param name clashing) is 
> split between the /crud/setup_order and the "list" template.
> 
> You can find a working example of this setup (which I've used in some 
> production apps) in a sample application named CrudApp, listed under the 
> "Examples" section in the cat wiki home page.
> While porting it to dbic (it all started out with cdbi), I'm also trying 
> to rething the whole approach, which I don't find particularly elegant 
> (some of the template code has roots in the factory list template 
> provided with Maypole...).
> 
> 
> HTH
> 
> 
>> _______________________________________________
>> List: Catalyst at lists.rawmode.org
>> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
>> Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
>> Dev site: http://dev.catalyst.perl.org/
>>
>>
> 
> 

I forgot to add that I'll be glad to discuss any issue involved in this 
kind of problems :-)

-- 
Marcello Romani
Responsabile IT
Ottotecnica s.r.l.
http://www.ottotecnica.com