[Catalyst] using REST within the app

[John Napiorkowski]

--- stephen joseph butler <stephen.butler at gmail.com>
wrote:

> On 5/24/07, John Goulah <jgoulah at gmail.com> wrote:
> > What are some of the patterns people are using to
> implement this?  Any other
> > thoughts?
> 
> People are going to hate me for saying this... but
> I've started to
> adopt the Java bean paradigm for my Catalyst app. To
> the point where I
> even have a whole MyApp::Bean hierarchy (skip to the
> bottom if you're
> already gearing up for a big paradigm fight).
> 
> Why? I had this nice little CRUD app that did what I
> wanted. But then
> I started looking at adding XMLRPC support, and
> other things.
> Reviewing my code, I realized I couldn't just call
> my existing methods
> because they all assumed things like:
> 
> 1) Parameters would come in an HTML::Widget or some
> CGI like interface
> (param, params, parameters, etc). When dealing with
> XMLRPC this isn't
> true.
> 
> 2) Errors would just be stuffed into the stash.
> Which is fine if
> you're going to render them, but isn't as nice for
> other solutions.
> Suppose I needed to add SOAP support later. Errors
> should come via
> SOAP exceptions.
> 
> 3) That the context would be able to provide things
> like the current
> user. With XMLRPC, sometimes the external app would
> need to feed the
> user to my backend, so what's in the context would
> be wrong.
> 
> 4) The general assumption that the content in the
> stash was going to
> be rendered. Some methods would fetch several things
> from the database
> and stash them because that's what the templates
> would need. But with
> XMLRPC, it was a waste.
> 
> I happen to have done some work with JavaEE and am
> familiar with the
> design pattern, so that's the solution I reached
> for. It's still MVC,
> but the controller has two parts.
> 
> A) The servlet, which corresponds to Catalyst
> controllers. But the
> servlets don't do any of the actual work; they just
> marshal the data
> between the HTTP interface and your beans...
> 
> B) The beans, which contain all the business logic.
> These interact
> with the model, manipulate it, and then return the
> results to the
> servlets. Beans should never be written with the
> transport (HTTP,
> SOAP, XMLRPC) or view in mind: all that's the job of
> the servlet. If
> the view needs extra data from the model for this
> transport, then it's
> the job of the servlet to fetch that.
> 
> This might or might not work for you. I'm not
> interested in starting a
> design paradigm war; I understand they all have
> their own strengths
> and weaknesses. Just thought I'd throw this out
> there

I don't think this should start a flame war; I think
the general consensus on best practices is that the
controller should be very thin, ideally you should be
able to simple set up your controllers with
declaration s in the config files and then you have
action classes that link up with domain model through
some interface logic, which are separate from
Catalyst.  This way you can use the same underlying
stuff for cron jobs or other needs, such as RPC.

So I think we are starting to come to that point, just
maybe we all don't have a canonical example of the
best way to approach building that layer.  The Mango
project has something like that and looking at the
source for that has given me a lot of things to think
about.  Reaction is a project that is one step up from
the domain model and sits between it and Catalyst to
offer a clear means of linking the two (Someone PLEASE
correct me if I'm wrong about Reaction).

--john

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com