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

[Jim Fulton]

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.

Cool. :)

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

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

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

Cool.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org