Peter Speltz wrote:
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.
I just mean that you set it by saying "$r->config->{uri_base}". And
that setting is put into a template variable called "base" in the
Maypole::View::Base::vars sub.
But the only place any config information can be set in standard Maypole
is in $r->config. I think that was a bad design decision but that
conversation's back in the mail archive somewhere.
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;
Turns out I had thought about it a bit - Maypole::Plugin::Path::URI is
in the archives of this list somewhere :) That's what I currently use.
And Dave Baird thought about it. His Maypole::Plugin::LinkTools is up on
CPAN. But both those plugins are still request-centred. At the next
revision I'll make Path::URI more presentation based.
The current version does have some support for multiple URI bases, though.
Where object is "Presentation" Type right ? I like that too. Let me
see if I can sum up the structure you have in mind:
Controller -- Handles apache request controls dictates flow.
Yup, and the Request is the instance data for a particular request.
Presentation -- Presents the web interface to the model. Defines
actions, the uri base for this model, and form inputs (?). Sets
template variables. Delegates data manipulation to model.
Yup. Forms are a bit awkward (as usual :) The validation needs to be
done by the Model (because it's to do with data integrity in the model
and because you might want to carry out the same operation in a
command-line script). But the form itself must be part of the View (it's
HTML, for starters). That separation is another thing I need to do.
Model -- Simple a plain class used to manipulate data in a table. Can
be used outside maypole without issue and knows nothing about Maypole
or anything else in the framework.
Yup. It's not simple, though. Most of my code is in the model. All the
'business logic' that understands how to manipulate my data.
View -- Maypole::View type class and the templates
Yup. My templates have become more complicated as I've built my
application and I think that was a mistake. They should be as simple as
possible - simple for the user and the designer. Being able to take code
out of the templates is one factor in where I want to go with my
Presentation & Model separation as well.
That sound about right? Makes sense to me. Simon actually said he
should have separated out the actions from the model. I did not fully
appreciate it at time but I see the benefit now.
Except for one thing: It is trivial to set up a cdbi class on a table.
How much of the code do you actually reuse across Maypole and non
maypole processes ? . The part I use outside of Maypole is simple the
3 or 4 lines of code to setup the class across the db in general but
I could see how you could share more model activity than that.
I have about 6000 lines in my CDBI model classes.
At any rate it seems it would be fairly simple to factor out a
Presentation layer. Could base presentation on the model class or
have it delegate to it. I think i like delegation but that may make
some backward incompatibilities. I wonder what Catalyst does ?
Backwards incompatibilities are a given for me :)
Cheers, Dave
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Maypole-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maypole-devel
