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.

As for browser2:pagesFromClass, creating a dynamic subclass that inherits from the original class seems most straightforward. After all, we already have a class...

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 />.

This too is magic, but presumably it is less magic than generating a class.

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...

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
attribute option.

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
class attribute.

All of this sounds good.

BTW, I would also like to see the for attribute made optional, as it is
for the adapter directive.

Sounds good.

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.

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to