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'.
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).
So if the data model needs config information, it should be explicitly
passed in using its own APIs.
Maypole's model currently has some aspects of the data model (e.g. extra
relationship methods) but is mostly presentation. As we've noted before,
config information is also all pushed together and might be better
separated for use by the View, Presentation, Model, Controller etc.
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!
Currently I set the controller class as class data in each model in
the "setup_model_class" hook. . Then i access it like
$class->controller->config{uri_base} and what not.
uri_base is actually config for the View, isn't it? That seems to be the
only place it's used.
I found this very useful when different maypole apps mingle with each
oother. For instance when an Employee has_a Customer and they are
controlled by two different Maypole apps and you want to bounce around
between the two. . Having access to the controller for a class is
crucial to linking to it. Also theres other useful configs in classes
controller.
Any one have any objections to this? Any ideas on implementation?
Should the whole object be passed in right before the model is
processed perhaps? Or should the class name and thus class data be
sufficient?
Cheers, Dave
-------------------------------------------------------
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&kid=110944&bid=241720&dat=121642
_______________________________________________
Maypole-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maypole-devel
