[Zope3-dev] RFC: The browser:page compromise

[Philipp von Weitershausen]

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

Philipp