On 2/13/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
> What internals? That a factory is a utility?

What interfaces to use in which case, and how they all map together.
Adding a page with browser:page is trivial. I don't really care that
you can separately define up a whole host of adapters, one for the
view-class, one for the menu item and one for something else, and I
don't want to have to care. Having a ZCML that lists a long list of
adapter statements instead of a browser addform statement that does
all of it wouldn't be an improvement in my opinion, but if you look at
the reasoning in your proposal, then it would be a natural next step.

Sacrificing understandability for an abstract cleanlyness is not often
a good thing.

> > Depracating specific statements is comparatively a no-brainer.
> Good. I guess then we can drop this discussion and just do it :).

Yes, except the browser ones. ;) I'm for fixing addview instead of dropping it.
(I said addform before, right? I meant addview).

> > That's a good point. But maybe then it should be made into an
> > on-off-switch, instead of a defining switch?
> Perhaps. This isn't the scope of my proposal though :).

OK, so if we look at the statements only, and not the rationale or
potential followups, then I'm +1 on all except addview. Lets keep
browser:* out of this for this time, and see if there is something
that can be improved there later.

> This isn't part of the actual proposal but just some random thought. However,
> there will be a proposal in the future that'll deal with the form stuff, and
> if it's only about getting rid of zope.app.form ;).

I'm already +1 on that. ;)

Lennart Regebro, Nuxeo     http://www.nuxeo.com/
CPS Content Management     http://www.cps-project.org/
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to