Surprisingly I'm actually doing a proof of principle on the same theme. I'm developing a set of MVC classes which tie in with either tt2 or mason.
I've got abstract Model, View and Controller classes. View can be subclassed into HTML, XML, whatever. I'm using normal classes at the moment, but if I get the go ahead, I'll be replacing these with some sort of pseudo-hash framework. My controller object would use the request object and the environment to determine a framework/templates and which overloaded Controller to generate. There is a generic events handler in the base class, which gets overloaded and which specialises the associated model object for the particular view subclass. I haven't looked at pre-reading the model and passing it into the first content handler, since in my case the model is likely to emerge from a large dataset. Once possible idea, floating in my head is to follow a principle adopted by the first company i was with, in that I could have a transitory daemon through which the data is called - this could possibly cache models requests, preventing second re-reads; also checking to see if the underlying model has changed, as per the original MVC paper. I guess that we can then reaccess the model at any point thereafter so that the the controller doesn't need to reaccess the data. Another point would be to cache the final generated templates, so that the view and controller override interaction with the model, where this data is already persistant. Got my basic framework in place - might make it my first cpan release if I can figure out how - want to share ideas? fiq On Tue, 26 Feb 2002, F. Xavier Noria wrote: > As an exercise studying mod_perl I am trying to see how could the MVC > pattern be implemented. I've thought a possible approach would be to > write the model using normal Perl classes, and controllers and views > with Apache modules. > > I suppose that controllers would use internal redirects to call the > views, is there a way to pass Perl data this way? For example, in the > hangman game in O'Reilly's book a controller would load a session from > the cookie, process user's guest, modify the state and redirect the > request internally to the view. Ideally the view shouldn't read the > data to display from the database again... could it be passed somehow by > the first content handler? > > -- fxn > >
