[Catalyst] Program the logic

[Marcello Romani]

Nilson Santos Figueiredo Junior ha scritto:
> On 6/29/06, Brandon Black <blblack at gmail.com> wrote:
>> 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.
> 
> It's View-agnostic but then the View still isn't Controller-agnostic.
> 
> Actually, after some thought this might be the real question that'd
> solve my issues: how to properly decouple Controller from Views?
> 
> I'll give you a real world example that's actually already in use in
> an implemented (but evolving) system. I've got a somewhat generic
> table widget. This table contains items that can be either active or
> closed. Sometimes the closed items should be displayed along the
> active, other times they shouldn't, but there's always a button
> "show/hide closed items". It's currently implemented entirely in the
> View, since the controller IMO shouldn't really need to know if the
> closed items should or shouldn't be displayed.
> 
> That involves doing bad things such as using c.param() from the View
> but it really was the only practical way (i.e. DRY) I could think of.
> So, any suggestions are welcome. ;-)

I know it sound obvious (and probably it is) but the only way I can 
think of right now to avoid using c.param() in templates is to implement 
visibility of parts of the page using Javascript. Something like 
showItem() and hideItem()...

As an example, one could manage expand/collapse operations on elements 
of a tree-like view using regular links with cgi parameters (therefore 
using c.param() in the view) or manipulating the page using javascript 
functions, avoiding page refreshes.

my $1 cents... :)

> 
>> 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...).
> 
> But how do you specify which actions are supposed to get the wanted behaviour?
> How do you handle pages with multiple resultsets being displayed? I
> think the convention could quickly become ugly. If you threw in some
> AJAX stuff in the mix it might even get uglier still.
> 
> But I'd be *very, very* happy if you showed me I was wrong. ;-)
> 
> -Nilson Santos F. Jr.
> 
> _______________________________________________
> 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/
> 
> 


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