Philipp von Weitershausen wrote:

I've long been thinking about how to make <browser:page /> simpler and
less magical. Some radical ideas weren't received well and I couldn't
convince even myself 100% that they were the way to go. Other
brainstormings were dead ends.

I therefore call this proposal a compromise. It simplifies, but it
shouldn't annoy (Tres...). Note that I'm specifically only addressing
<browser:page />, not <browser:view />; nor am I coming up with a
framework for dealing with forms and their handlers (Jeff...).

'Nuff said. Your turn :)

I've been focussed on my adapter branch so didn't pay attention
to this until I saw some discussion about it on IRC last night. :)

I've only skimmed this thread.  I don't have time for more.

I'm -1 on this proposal.

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.

We can arrange for browser:page to not generate a class when used as
you propose using browser2:page.

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.  This too is magic, but presumably it is
less magic than generating a class.

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.

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


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to