[Catalyst] Program the logic

John Napiorkowski jjn1056 at yahoo.com
Fri Jun 30 04:36:36 CEST 2006


You can use some of the available plugins to help with this.  There are plugins to serve controller actions as xmlrpc or json for example.  I've also been doing some lightweight services with RSS and ATOM.  I don't specifically see something for SOAP, but I doubt it would be hard to make.

I think Catalyst currently collapses a couple of things into each part of the MVC model.  For example what we call a View could be a couple of different things.  Usually it is some sort of serialize for the Stash, right?  But if you chain together several views you might have the first view serializer the stash into something (like RSS) and then pass that to an XSLT transformer to generate HTML.  That second transformer would probably act on what it finds inside of $c->response->body instead of on the stash, although this is a bad example since the current xslt view for catalyst looks for something in $c->stash->{xml}.

I think if you are reallying looking avoid stuff like "c.param" in your view you can use this method, just serialize everything your need to a common xml type format (the stash, params, etc) and then use XSLT or the XSLT stuff in TT to transform to html.  I started out going this way but didn't honestly find an advantage.  Since all my view templates are only going to be used for catalyst I didn't have any trouble with putting some catalyst stuff in the template.  In my situation the designers only really get to play with the CSS, not the html so I don't need to worry about designers messing up the TT code.  --john



----- Original Message ----
From: Matt S Trout <dbix-class at trout.me.uk>
To: The elegant MVC web framework <catalyst at lists.rawmode.org>
Sent: Friday, June 30, 2006 7:29:13 AM
Subject: Re: [Catalyst] Program the logic

Matthieu Codron wrote:
> Brandon Black a écrit :
> In J2EE projects, the layer model is more like "MSCV-I", for Model --> 
> Service --> Controller --> View, the "I" standing for Integration layer 
> (Spring for example, or Catalyst in Perl)
> 
> What is missing in Catalyst is that "Service" layer. But it's not a big 
> deal in most cases, IMHO.

Nah, you just stick that layer in your model directory and the domain 
implementation itself somewhere else. It's not really missing, it's more that 
the tutorials, convenience components etc. all focus on small apps which don't 
need that extra layer of abstraction so much. By the time you really need the 
split to be explicit, you've probably got enough architecture for that not to 
be a problem (or if you haven't you've got bigger problems than any related to 
Catalyst :)

-- 
      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 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/






More information about the Catalyst mailing list