Quick note, (I will definitely read those articles. Thanks Dave. ) I think refactoring will help identify the ribbons and the structure of the Maypole request. I'm picturing each request as a M V C all going around the maypole , they go aournd each in turn wrapping the ribbon until there is the pretty picture left. Since its a computer, any given component can stop, pick up a new ribbon and go, or cut out . etc. (I really dont have much experience with real life Maypoles. We did one at a wedding i think once. and all i remeber is going around and around until my ribbon was all the way wrapped. and maybe ducking under and over some other ribbons. It was fun. )
Anyway , when the handler guts in refactored, the different hooks will all be ribbons i suppose. Ohhhh. A graphical debugger of the workflow would be NEAT! Instead of wathcing the error log wathch a maypole. I'll put that on my todo :) I have a litlle OpenGL experience . Anyway, enough dreaming and back to work. cheers, On 11/8/05, David Baird <[EMAIL PROTECTED]> wrote: > On 11/8/05, Dave Howorth <[EMAIL PROTECTED]> wrote: > > On Tue, 2005-11-08 at 10:37 +0000, David Baird wrote: > > > > > > In fact, there's very little code in Maypole that counts as V - that's > > > all in TT and the templates, and most of the code in > > > Maypole::View::Base and ::TT is about communicating with the View. > > > Similarly for the model, but it's a bit more complex, because in a > > > simple Maypole app, like BeerDB, the only model is the Maypole model. > > > But in a complex app, the Maypole model becomes the ribbon that joins > > > the Controller to the underlying model. > > > An interface to the M. > > > > Most of this stuff is what I call the Presentation. I'm a fan of Martin > > Fowler and got that term from his patterns. There are many pages on his > > site, which is a bit disorganized, and I still haven't completely > > figured out my take, but see for example > > http://www.martinfowler.com/eaaDev/OrganizingPresentations.ht > > http://www.martinfowler.com/eaaDev/PresentationModel.html > > Yep, that seems to describe what we've got pretty clearly. The browser > is a thin client, and we get synchronization for free (in each HTTP > request event). The Maypole model receives events (the Exported method > in the URL) from the view. It does some processing and changes values > of certain variables. Then the view (Maypole::View::Base) is > responsible for picking up these new values (via the vars() method) > and displaying them in the templates. > > I'll add 'Presentation Model' and these links to the terminology > chapter, I think they're very useful. > > d. > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Maypole-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/maypole-devel > -- pjs ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Maypole-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/maypole-devel
