MVCR pattern (was Re: [Catalyst] Bing!)

[Matt S Trout]

On Fri, Aug 12, 2005 at 07:00:14AM +0200, Sebastian Riedel wrote:
> Am 12.08.2005 um 00:39 schrieb Sam Vilain:
> >Jesse Vincent and Autrijus Tang's "Bamboo" module is designed to be a
> >real MVC state machine with abstracted and secured logical actions  
> >that
> >can plug on top of request processing frameworks like Catalyst or  
> >Mason.
> >So, if somebody writes a Catalyst::Bamboo, does that mean that  
> >Catalyst
> >wasn't MVC in the first place?  Or just that the term MVC is
> >sufficiently vague as to be deemed useless?
> 
> I wouldn't call this "real MVC", these (very elegant) Seaside like  
> state machines are something built on top of the MVC pattern.

Yes and no. It's arguable that actually they're a set of View objects with
a partial Controller implementation. Trying to model this directly into
Catalyst is giving me a lot of pain though; possibly I've picked the wrong
definition of MVC for the phase of the moon or something.

Anbody who's interested in Bamboo should probably have at least a quick peek
at BAST; it's marginally less vapourware than Bamboo and autrijus and I have
been thinking much along the same lines (or at least so he told me once in
between the bits that went over my head).
 
> The main problem of state machines for webapps is that they are  
> limited to (plain old) multi page wizards, it would be a mess to use  
> them in "modern" more dynamic apps using things like AJAX.

Depends how flexible your concept of a state and an event are. Plus once
you start specifying things by exception (think p6 OO's "but") it gets
... well, I'm intending to be able to do non-AJAX and AJAX merely as an
exception against the concrete builders. I think they'll be concrete
builders, but probably I just don't know what I'm talking about yet.

Maybe you could demonstrate such a "modern", "dynamic" app by ACTUALLY
RELEASING SHARKPOOL :p

> But as i agreed with Autrijus, state machines are a nice backup  
> mechanism for browsers that don't do AJAX or apps with a special  
> requirement for accessability.

Or apps where you want to be able to separate the workflow and the interface,
thus allowing a web browser, a perl script using REST and an IRC user talking
to a bot to access the same functionality and logic. Or just allowing better
code re-use :)

> I can imagine having such hybrid systems for higher level widget  
> toolkits.

I'll settle for a useful, skinnable HTML widget toolkit at all. And no
I don't believe TT's Splash! collection counts. Nor does *spit* ASP.Net's
attempt. Seaside seems to be doing pretty well, but I'm not sure they're
sufficiently skinnable for my tastes even so.

-- 
     Matt S Trout           Website: http://www.shadowcatsystems.co.uk
  Technical Director        E-mail:  mst (at) shadowcatsystems.co.uk
Shadowcat Systems Ltd.

 + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +