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 <[EMAIL PROTECTED]>
To: The elegant MVC web framework <catalyst@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@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/
_______________________________________________
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/
