Philipp von Weitershausen wrote:
Jim Fulton wrote:
The browser2:pageTemplate and browser2:pagesFromClass directives
don't really gain anything, because they still generate classes.
They don't have to generate classes. They could just do clever
factory construction to avoid class creation.
I don't think they can. browser2:pageTemplate has to create a class that
has 'request' and 'context' attributes because that's what
ViewPageTemplateFile expects to be assigned to.
It can use a preexisting generic class that it provides.
It doesn't have to create a new one
for the view.
As for browser2:pagesFromClass, creating a dynamic subclass that
inherits from the original class seems most straightforward. After all,
we already have a class...
If that's how you feel, then what's wrong with browser:page?
In any case, you could have a factory that binds each template to an instance of
the class and returns the bound template. That is, return the bound template
rather than returning an instance of a generated class that gas a __call__
attribute that is the template.
We can arrange for browser:page to not generate a class when used as
you propose using browser2:page.
Sounds like a good idea.
Note that there are two sources of magic in browser:page:
- providing a template
- specifying a permission
When adding the ability to specify a template, I chose to use class
Another approach would have been to augment the factory. This is the
approach that Tres described. This is what the adapter directive does
when a permission is provided. Basically, it replaces the original
factory with a factory that calls the proginal factory and then adds
the security information to the generated instance. We would need to do
this for browser2:page as well.
browser2:page just uses the directive handler of the 'adapter' factory.
In fact, it's not much more than that. It's just a shortcut for writing
<adapter /> and possibly <browser:menuItem />.
On IRC, I thought you said it also has menu support.
Honestly, if it wasn't for the lack of menu support in the
adapter directive, I'd just use that.
This too is magic, but presumably it is less magic than generating a
Interesting. For some reason, i've never thought of that as magic.
Making sure everything is security-wrapped isn't trivial, after all. I
guess I'd expect a complex solution.
Perhaps the reason why I didn't think it was magic was that the original
factory *does* end up being called. You end up with the object that you
expect, not with an instance of some magically created subclass. The
object just happens to have some security info attached to it...
Sure. It is less magic.
I suggest we add a factory attribute to the browser:page directive.
When a factory attribute is used. then a class would not be generated.
The bahavior would be much as you've proposed for browser2:page. I would
allow a template to be provided. If a template is provided, then
the given factory computes the object that is bound to the template.
In this case, the view object is actually a form of bound template.
Of course, it would be an error to use the class and factory options
together. It would also be an error to use the factory option with the
As far as best practices are concerned, people could advocate for
using factory rather than class. I would certainly support this
point of view. :) Eventually, we might even deprecate use of the
All of this sounds good.
BTW, I would also like to see the for attribute made optional, as it is
for the adapter directive.
I don't think I'll get any of this done in time for May 1st, though.
Five is calling for a fixup before the feature freeze. So it'll have to
wait for Zope 3.4. That's ok, in the mean time we can advocate sane
usage of browser:page.
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list