Peter Speltz wrote:
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.
Hi Peter,
The presentation is something different to the view (template), IMHO.
Ideally, the view shouldn't know anything about the model and the model
definitely shouldn't know anything about the view. That leaves a gap -
the presentation - which translates between the two. It roughly
corresponds to Maypole actions, plus form-handling. But any business
logic in custom actions is misplaced, it belongs in the model. Dave
Baird was also suggesting something like this in his FormBuilder model,
IIRC.
The View class takes data from the request/controller and model and
stashes it in template variables.
Yes, this part of Maypole's View is part of my presentation.
In the templates you have the request and model objects to use.
Yes, that's true but I think it's a mistake. The templates should only
need to see data prepared for them by the presentation, which perhaps
just extracts it from the 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).
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.
My model is used much more in other applications. Maypole is just a
browser I occasionally use. 99% of updates are done by programs launched
either by cron jobs or by other specific CGI scripts.
At the moment, I haven't got the separation quite right and all these
scripts have to pull in a bunch of Maypole classes that just sit there.
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 ?
I don't really understand what you're doing here.
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.
I don't know what you mean here.
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.
Do you have model class specific code in your controller? That knowledge
should be in the presentation, IMHO.
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.
Yes, Maypole just doesn't have the concept of more than one anything,
really.
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
I haven't thought about it but off the top of my head I'd prefer:
link = $obj->config->uri_base . "/" . $obj->table;
or better yet:
link = $presentation_object->link;
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
