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:[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
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to