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

[Philipp von Weitershausen]

dev at projekt01.ch wrote:
>> dev at projekt01.ch wrote:
>>>>> That confuses me even more. I *am* proposing changes to the 
>>>>> browser:page directive...
>>>> Hmm, never mind. I think I understand what you mean. You'd like to 
>>>> see new directives, instead of changing the old ones. Right?
>>> Yes, I think it's very important to bring a little stability to the
>>> Zope3 framework rather then change every release such fundamental 
>>> parts like directives.
>> I will accept this criticism when you tell Jim that his work 
>> on jim-adapter branch was wrong for that same reason and when 
>> you tell me (which you haven't) that my work on 
>> MakeZopeAppSmaller is also wrong for that reason.
> 
> That's a difference. Jim's *adapter* refactoring will bring us 
> a speed up and solves some problems in the adapter registry
> implementation. (lookup multiadapter by it's registration tuple).

That's just the first part of jim-adapter branch. The second part is a
very different (and much simpler) API for local registration. Code that
uses the old API will see lots of deprecation warnings.

> Your proposal is just a *cosmetic* change which forces us to
> change existing projects and like Florent says: We have to 
> write additional python classes for just that. I don't buy this 
> as really usefull. 

Florent? I must have missed his reply...

You don't seem to understand my proposal, though. You WON'T have to
write additional python classes. That statement just isn't true.

>> Sorry, I just don't buy it. We're still refactoring some key 
>> packages like zope.component and you're trying to shoot down 
>> a refactoring of 3 ZCML directives?
> 
> Yes, 
> Why the hell do I have to write additional python classes for 
> each page registration after your refactoring?

You don't!

> If we do this, I can add the browser:page directive back as 
> a high level directive and then the need for write additional
> python classes is just a YAGNY like before. Is this really a 
> improvment?
> 
> Another problem is, that we have mor then 6 projects build
> with zope3 up and running. Such a improvment is not nice
> and will force us to change more then ~300 existing page 
> registrations. 
> It's a horror to think about how many python class we have 
> to write if we do this simplification!!!

You don't have to! You got my proposal 100% wrong. My proposal will
never make you write new classes (that's the compromise!):

a) If you have a page tempalte without a class, you can continue like
that. Just use browser2:pageTemplate instead of browser:page

b) If you already have a class, you just need to make sure it's a proper
browser page (IPage/IBrowserPage conformity). Then use browser2:page
instead of browser:page.

c) If you have a class and a template, put the template on the class via
ViewPageTemplateFile and use browser2:page instead of browser:page.

d) If you have a class from which several pages are created (from
different methods, perhaps), use browser2:pagesFromClass instead of
browser:pages.

In cases a) and d), you will simply have to switch to a different ZCML
directive. In cases b) and c) minor adjustments to classes are
necessary, mostly the classes have to be given a (different) base class.

> You totaly ignore that Zope3 is not a experimental framework 
> now and stability is also a criteria which should recognized.

Then let's call of all improvements that will lead to deprecation of
APIs and directives. I don't think that's a very sane way to go.

> Please recognize that some people have built applications
> with zope3 since more then 2 years now.

So have I.

> And respect that they are not willing to just change everything wich
> forces them to go other ways then before without a real
> *improvment*.

Perhaps we measure improvement differently. My proposal states a bunch
of problems which will be gone when the proposal is implemented. To me,
that's improvement.

> btw, I don't dislike the refactoring at all, but I just dislike
> that we have to update our projects for *this* simplification.

I realize that. Hence I've changed the proposal to suggest separate
directives. They're also already implemented. See my Update post to
zope3-dev.

> We have at least to provide both way of registration.
> Perhaps it's really time to add a higher level directive pool
> for such refactorings. Is this a option for you?

No. ZCML is not a high level thing. Jeff shell explains this very well
in http://griddlenoise.blogspot.com/2006/03/zcml-needs-to-do-less.html.
Bottom line: If we want something high-level with lots of automation
etc., then we should simply use Python for configuration.

One of my regular readings is http://thedailywtf.com, mostly because
it's amusting. The other day I saw a post
(http://thedailywtf.com/forums/69415/ShowPost.aspx) which reminded me
very much of ZCML: ZCML tries to be so flexible and high-level and
provide so much automation, that in itself is adopting features from
Python. Just remember the zcml:condition feature that we recently
brought in. It's the "if" statement in ZCML...

Philipp