Nilson Santos Figueiredo Junior wrote: > On 6/29/06, Matt S Trout <[EMAIL PROTECTED]> wrote: >> Nilson Santos Figueiredo Junior wrote: >>> 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. ;-) >> No, it's the best separation of concerns, I think. The trick is to make the >> View smarter, which is a hard problem for webapps because of the degree of >> flexibility in styling required (ASP.Net has great shiny components, but any >> ASP.Net app looks like an ASP.Net app). Encapsulating the c.param bits in a >> TT >> plugin or three might be a good halfway measure. > > I couldn't really get the point of your ASP.Net analogy nor could I > imagine how to encapsulate c.param() bits in some TT plugins (well, > actually, I could think of aliasing c.param() to param() but this > probably wasn't what you meant). So, could you please elaborate on > this?
Template::Plugin::Class will load an arbitrary class. Why not have a plugin that grabs $c from the context and hides logic for the view code? Or a set of subrefs put into the stash, or whatever ... -- Matt S Trout Offering custom development, consultancy and support Technical Director contracts for Catalyst, DBIx::Class and BAST. Contact Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ + _______________________________________________ List: Catalyst@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/