On 4/18/06, Dave Howorth <[EMAIL PROTECTED]> wrote: > Peter Speltz wrote: > > I propose in 2.12 or something, (I use it now) that the Controller or > > Maypole Request class and/or object should be stashed in the model. > > I think Maypole conflates various objects that should be separate. The > controller and the request should be separate objects - Maypole has just > one. The [data] model and the [web] presentation should be separate > objects - Maypole just has its 'model'. >
Can you lay out how you think things should be structured -- ie the components and whats in them ? Maypole's presentation layer is separate from model -- its the template. The View class takes data from the request/controller and model and stashes it in template variables. In the templates you have the request and model objects to use. > I definitely think that the [data] model should NOT know anything about > the presentation or the controller. The model should define APIs to > which the request should conform in order to pass data either way. The > rationale is 'separation of concerns' - pragmatically, so the model can > be used in other ways than just in a Maypole app (e.g. loader scripts). > I like the idea of model being able to be used outside of Maypole. And i think this may be a good direction to go. I'm just not sure how to do it or if it would not complicate most cases. The only issue I have with my model being used outsied Maypole (Now that i switched to CDBI plain) is the method attrs. And of course methods that use various Maypole components such as the request. > So if the data model needs config information, it should be explicitly > passed in using its own APIs. Thats sort of what i do. The request initializes the value of "controller" in the model at setup. This way, If a model is being used by Maypole, it has that value set. If its not, it does not have that value set and I have no reason to use it outside of Maypole. > So I'm not very clear what I'd do about your question unless and until > there's a major revision of Maypole's model. > > But in general I'd prefer to see classes untangled rather than extra > cross-links added. Maypole's structure is already complicated enough! Assuming Maypole's structure was adequate for the sake of this discussion, I dont think what I prpopose is entangling. Why shouldnt a model class used in Maypole have access to $r ? It does in each action. However sometimes you use related models within actions that have a different class of $r. So why shouldnt that model have access to at least the class data of it s own $r ? Perhapse another solution would be to just make the uri base to each model class data of the model and set that in setup. But I agree, there should probably be some effort put into the MVC structure. > uri_base is actually config for the View, isn't it? That seems to be the >only place it's used. No . Its a request config. The View stashes in the template arg "base" before it processes it. To me, each CDBI object has a uri base in my apps. Like, I forexample , linking to an old object in an old database from within the new one. $class->has_a(old_id => $OldClass); Now , that object is automatically assumed to have the same URI base as the rest and is displayed with broken links everywhere. When really in the code you just need to know that the Web representation if this object is controlled by from a different controller and use that controller's uri_base. Right now , Maypole assumes one controller for all Model classes ever used in the app. That could be more of an entanglement than asking the model class what it's controller is. I think i like : link = $obj->controller->config->uri_base . "/" . $obj->table; # Object independent of current controller object vs. link = $r->config->uri_base . "/" . $obj->table; # Object entangled with current controller object ??? ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Maypole-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/maypole-devel
