Congratulations Sebastian :)
I've got quite a few bits and pieces that I will take a good long look
at - some of them may be useful patches. I also have a couple of
suggestions that I'll mail to the developer list - they are mostly to
do with breaking up some of the existing code into smaller chunks to
make inheritance easier.
I don't have a great deal of time at the moment but I'll try to get you
a couple of patches within a couple of weeks (for some reason selling
house + buying house + 1 month old son + finally getting divorced from
ex so I can marry my partner + full time job + part time job seems to
be filling my days, dunno why).
On 4 Sep 2004, at 20:36, Sebastian Riedel wrote:
> Hi,
>
> As of today I am the new maintainer of Maypole.
>
> First I would like to thank Simon for his great work and wish him good
> luck for his missionary future! (btw. do we have to call you Father
> Simon then? ;)
>
> These are some things I would like to see in the near future, post any
> additions or complains right here.
>
> Todo:
> * fix all open bugs (pager and search results, pager and list
> order...more?)
I'm about to start work in a pager for my current project. I will see
if I can make it generic.
> * put POST and GET data in $r->{params} and deprecate $r->query
Yes! I think that this needs to be examined rather carefully - I'm not
sure that it handles
situations where multiple parameters have the same name correctly (nor
am I sure what
'correctly' means in this situation).
> * call additional_data() and authenticate() for plain templates
I agree :)
> * make the templates valid XHTML
> * better documentation and more complex examples
I mailed the list about the idea of introducing Template caching a
while back - the idea of creating a Template object and re-using it.
I've had some further ideas about this and would appreciate some
feedback before writing the code. The basic problem with caching
Template objects here is that we are in a 'disconnected' environment.
TT2 gives us a very useful tool - the INCLUDE_PATH parameter to
Template->new can have code references and objects as part of it.
However, the current include path depends on Maypole's concept of which
table is current. That concept changes from request to request. It may
also depend on which Maypole application is making the request -
clearly the cache should allow a single web server instance to serve
multiple Maypole instances.
Finally, the caching mechanism needs to be simple enough that it
doesn't add too much overhead if used without the sort of semi
persistence that comes from running under mod_perl. Oh, and it probably
shouldn't rely on mod_perl. I guess that this could be handled by
simply supplying a new Maypole::View::XXX rather than replacing
Maypole::View::TT.
Having said all that then, the problem comes down to 'how do I
communicate a change in the path to TT2 without creating a new TT2
object?'
As I said above the code reference and objects that can be part of the
TT2 INCLUDE_PATH parameter are going to be our friends in this
exercise. I think the best approach is to create a small module to
allow us to communicate with TT2. I am planning to do the following:
add a class attribute to my View class that stores a reference to a
hash. This hash will store references to a two item list. It will be
keyed on the package name of the driver class (ref($r), that is). The
values stored will be a reference to an object in our intermediary
class and a reference to the paired Template object). There are reasons
for not storing a single Template object that I'll explain later.
when the template method is called on this View class it checks for a
cached template object. If found it calls a method on the intermediary
object to supply it the request object. If not found, it instantiates a
new intermediary object and a new TT2 object, passing the intermediary
object to the TT2 object as part of the INCLUDE_PATH parameter.
Having obtained references to the intermediary and to the TT2 object,
the template method will then call a method (let's call it request) on
the intermediary object, allowing the intermediary to gather data from
the request. The intermediary object must also provide a method called
'paths'. This should respond with the appropriate paths (no suprises
there). For paranoia's sake it should probably delete all the data it
used to generate that path immediately afterwards.
I'm suggesting a per application hash of intermediary and TT2 objects
to that these can differ between Maypole applications - in my own
applications, for example, I've been customising the TT2 object via
configuration to a fairly large degree on a per application basis
(using pre processed templates and wrappers, for example). I have a
feeling that this is probably not necessary under most circumstances.
Dunno.
So... the question is... does that all sound sane?
nic
_______________________________________________
maypole mailing list
maypole at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:56 GMT