[Zope3-dev] Re: RFC: The browser:page compromise
Lennart Regebro wrote: I'm -1 on this proposal. I agree, browser:page is too complex and magic. The reason for it's complexity and magic is that there are two things that clash: 1. The need to have simple and easy view registrations, and 2. The requirement that view must be callable classes. A publishable view must provide IBrowserPublisher. We happen to call such browser views pages. This requirement and this nomenclature has worked well since very early days of Zope 3. I'm not suggesting to change that. I'm just suggesting to change the awareness of that fact for the end user to make everything less magical. The second requirements mean that you have to create a lot of callable classes that do nothing particularily useful. There can created by the programmer, which is a lot of stupid work. Requirement 1 sais that we shouldn't do that. The result is that we then create them automatically which creates a lot of hard to understand magic. All this proposal does it to try to split that magic up into three different ZCML statements to make it slightly less complex. It is after all a compromise. I would like to see if there s a way we instead can actually fix the problem completely. Hmm, the goal wasn't to make things more complex. If you think that having three directives, each of which does exactly one thing, is more complex than having one directive that does everything together, I must have failed somehow. Fixing the problem completely is certainly a pious wish, but we may never get there. Hence the compromise. I'm trying to improve what can be improved now. Just see how much of a fuss this tiny proposal made already. Evidently we do NOT want to get rid of requirement 1, because then people will again find making views a pain. Therefore, lets think about f we can get rid of requirement 2. There are two parts to that requirement. 2a: Be a class that implements IBrowserView. IBrowserPublisher 2b. Be callable. Which is expressed by IBrowserPage. Basically, IBrowserPage extends IBrowserPublisher by a __call__ method. Can we get rid of one of these? Why? For example, could we have an optional argument on view registration that tells the view which attribute to be called? (I know, that's not possible when views are just adapters, it's an example). What's wrong with having to implement a specific attribute (__call__)? After all, having well-defined APIs means that you have to implement certain attributes/methods. We do and require it for lots of other stuff, why can't we require it for browser pages? It makes everything darn simple if you can tell people Just implement IBrowserPage when they ask how to write a publishable browser view. If we can't get rid of either 2a or 2b, we will either have to sacrifice requirement 1, and making views will be a boring pain, or have to have a lot of hard to understand magic with dynamically created classes. If we want to sacrifice the ease of registration, which this proposal does to a small extent Does my proposal really make registration harder? I think we in that case should go all the way and remove the browser:page completely. It can in that case be moved out to a separate product for people like me, who want it. Summary: I think that we at this moment should do either: 1. Nothing. 2. Remove browser:page and browser:pages completely. 3. Remove requirement 2a or 2b on views. #2 is what I'm suggesting so I'm not quite certain how to count the -1 from above. #3 I don't understand. Views are adapters. Publishable views need to provide IBrowserPublisher (this an old requirement in Zope3, you just never saw it because browser:page did magic). IBrowserPage makes IBrowserPublisher-compliance easy by offering you __call__ to implement. I can't imagine how it can get simpler than that. But I'm open to constructive suggestions. Thanks for your comments. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
On 4/23/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: A publishable view must provide IBrowserPublisher. We happen to call such browser views pages. This requirement and this nomenclature has worked well since very early days of Zope 3. I'm not suggesting to change that. I'm just suggesting to change the awareness of that fact for the end user to make everything less magical. Sure. All this proposal does it to try to split that magic up into three different ZCML statements to make it slightly less complex. It is after all a compromise. I would like to see if there s a way we instead can actually fix the problem completely. Hmm, the goal wasn't to make things more complex. If you think that having three directives, each of which does exactly one thing, is more complex than having one directive that does everything together, I must have failed somehow. Well, yes I do. I see that the code for the directives are less complex but it gets more complex for the users of these directives. The complexity has just moved. So it´s not actually more complex, just in different ways. I guess you can say that's why I´m -1 on the proposal. I'd like to get rid of complexity, not move it around. :-) Fixing the problem completely is certainly a pious wish, but we may never get there. Hence the compromise. I'm trying to improve what can be improved now. Just see how much of a fuss this tiny proposal made already. I know what you are trying to do, and I'm not saying that's a bad thing. I'm just saying that I don't really think this proposal does it, or at least not enough. :-) All I'm doing is trying to point out why this is so hard to fix, and maybe try to see if there is an alternative route. There are two parts to that requirement. 2a: Be a class that implements IBrowserView. IBrowserPublisher Right, sorry. 2b. Be callable. Which is expressed by IBrowserPage. Basically, IBrowserPage extends IBrowserPublisher by a __call__ method. Can we get rid of one of these? Why? Because that would fix the problem. What's wrong with having to implement a specific attribute (__call__)? Because it means that wee need to have one class per view. And that in turn means that we either have to have a lot of essentialy empty classes, or create magical classes dynamically. That in turn creates this complexity. I´m trying to see if we can get rid of it. Summary: I think that we at this moment should do either: 1. Nothing. 2. Remove browser:page and browser:pages completely. 3. Remove requirement 2a or 2b on views. #2 is what I'm suggesting so I'm not quite certain how to count the -1 from above. No, you are suggesting to refactor them and maybe rename them. My #2 is to deprecate them completely and do nothing else. Which, I think, is what you wanted to do before, but loads of people (including me ;) ) screamed. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
Lennart Regebro wrote: On 4/23/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: A publishable view must provide IBrowserPublisher. We happen to call such browser views pages. This requirement and this nomenclature has worked well since very early days of Zope 3. I'm not suggesting to change that. I'm just suggesting to change the awareness of that fact for the end user to make everything less magical. Sure. All this proposal does it to try to split that magic up into three different ZCML statements to make it slightly less complex. It is after all a compromise. I would like to see if there s a way we instead can actually fix the problem completely. Hmm, the goal wasn't to make things more complex. If you think that having three directives, each of which does exactly one thing, is more complex than having one directive that does everything together, I must have failed somehow. Well, yes I do. I see that the code for the directives are less complex but it gets more complex for the users of these directives. The complexity has just moved. So it´s not actually more complex, just in different ways. Is using a convenience base class really that much more complexity for the user? It's perhaps a little more typing, but it gives you less magic in return. Less magic is less complexity in a way. I think browser2:page is an extremely easy directive. Because it's so stupid. It will eat an IBrowserPage factory and register it as an adapter. Implementing IBrowserPage OTOH is also dead simple given our convenient base class. Just implement __call__. Perhaps I'm too deep into the matter to see the aroused complexity. What's wrong with having to implement a specific attribute (__call__)? Because it means that wee need to have one class per view. And that in turn means that we either have to have a lot of essentialy empty classes, Not sure what you mean by that. One page is implementing by one class. The implementation of the page is in __call__. So I can't see how these classees would be empty. They at least have a __call__ method. or create magical classes dynamically. That in turn creates this complexity. I´m trying to see if we can get rid of it. Be my guest. The browser2:pagesFromClass were added as part of the compromise so that people can conveniently put code for pages that use a lot of common code on one class. I admit that this will still have to use magic, however, there people explicitly choose to use magic. Currently they almost have no choice. Summary: I think that we at this moment should do either: 1. Nothing. 2. Remove browser:page and browser:pages completely. 3. Remove requirement 2a or 2b on views. #2 is what I'm suggesting so I'm not quite certain how to count the -1 from above. No, you are suggesting to refactor them and maybe rename them. My #2 is to deprecate them completely and do nothing else. So, basically, register pages and all other adapterish things with an adapter / directive? Fine by me :). Which, I think, is what you wanted to do before, but loads of people (including me ;) ) screamed. ... hence the compromise :) Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
On 4/23/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Is using a convenience base class really that much more complexity for the user? It's perhaps a little more typing, but it gives you less magic in return. Less magic is less complexity in a way. Depends on what you mean with convenience class. I don't mind convenient classes. But if I really need to create one class that does nothing except server as a placeholder for each of my pagetemplates, I wouldn't call that convenient. ;) So, basically, register pages and all other adapterish things with an adapter / directive? Fine by me :). Pretty much yes. ... hence the compromise :) Yup. And it seems the compromise was worse than the problem. ;) As Calvin sais: A good compromise leaves everybody mad. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
[EMAIL PROTECTED] 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. 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? Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: RFC: The browser:page compromise
Kamal Gill wrote: Stability is especially important for those of us learning Zope 3, as well as those who offer Zope 3 training. I realize Z3 is a fast-moving target, but making existing books and documentation obsolete doesn't help the adoption of such a fantastic collection of software, IMO. I also write on Zope 3 and train people. *All* of my recent attempts to make ZCML clearer and easier to understand comes from *direct* feedback from these trainings and from the readers of my book. ZCML as of Zope 3.2 is inconsistent and to someone who's new and doesn't know every little detail from behind the scenes it's very obscure. And then it also makes debugging hard which has bitten me personally quite a few times. I explained this is a reply to Rocky Burt in this thread: http://mail.zope.org/pipermail/zope3-dev/2006-April/019169.html Now, would you rather make an attempt to document the inconsistent (and hard to maintain, not to forget!), or wouldn't you rather make an attempt at fixing the damn thing? Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
Tres Seaver wrote:
- Deprectaion of an older, stable alternative, *no matter how grotty,*
should go hand in hand with *lots* of confidence that the new favored
alternative really is superior, and by enough margin to make the
switch worthwhile. In my mind, this means that the new
implementation needs to be rolled out *in production* and tested in
the wild *before* we can deprecate the older alternative.
I think that's a big burden for refactorings. Under such a rule, Jim
wouldn't be allowed to roll out neither his adapter registry
improvements nor his Component Architecture simplification.
Refactorings *need* a bigger burden than we have recently been imposing:
- Doing a refactoring right means adding BBB code, which itself
increases the maintenance burden for core developers.
- As an example, the twisted server became the *default* in Zope 3.2
in spite of the fact that it broke ZEO because the developer who
landed the change doesn't use ZEO, and hence missed seeing the
damage.
I guess we didn't have enough tests. Now we have a test that exercises
ZEO. Plus, we dealt with this problem before any final release (perhaps
even before the beta?). That's what alpha and beta phases are for...
My point here is that the 'refactor mercilessly meme has left people
feeling free to make chnages of debatable value (Twisted is *still* not
accepted in the Zope community as a superiour choice for publishing
HTTP),
With the current efforts of bringing Twisted to Zope 2, I'd say that's a
debatable argument. But I can see that you haven't accepted it as a
superior choice. Which is fine. But that's part of another discussion. I
presume there were proposals back then and there were numerous
discussions revolving around this topic.
I realize you've been bitten by some dumb deprecations, but as far as I
can see, they were all a) in Zope 2, b) made without a proposal, c)
probably not discussed.
Like Craeg Strong wrote in this thread, deprecation per se isn't bad. It
just has to be done carefully and right. He suggested that deprecation
warnings shoudl be very clear about what has changed and what the new
way of doings things is. I've tried to follow this paradigm when
deprecating a bunch of ZCML directives (ReducingTheAmountOfZCMLDirectives).
without full weight being given to the needs of folks who aren't
up to their elbows in the code every day.
- The packaging changes introduced in the 2.9 release cycle broke
usecases which many developers care about ('make inplace' is broken,
instance home testing broke, etc.) Worse, and ironically, the
breakage was incurred on behalf of 'zpkg', which is itself slated
(now) to be deprecated.
Forgive me if I'm a little rough on this subject, but here it goes:
I've had it with this whining about make inplace etc. It's been nearly
half a year since 2.9 is out and nobody has even made the attempt to fix
this so I guess nobody really needed it. Yet there's still whining. Yes,
I'm to blame for bringing zpkg to Zope 2 because the Zope 3.2 build
process strongly suggested it. If there were alternatives to zpkg,
nobody has suggested them and nobody seems to have explored them so far.
All I know is that everyone wanted Zope 3.2 in Zope 2.9 which is what
they got.
Zope 3 is a *library* for Zope 2 -- I don't see any necessary reason to
have Zope 3's packaging model drive Zope 2's.
As you describe it below, it was the easiest and first choice back when
I brought Zope 3.2 into Zope 2.9. My main objective was to bring Zope
3.2 up to date with Zope 2.9, not changing Zope 2's packaging mechanism.
Perhaps it was wrong doing it anyways just for the sake of having Zope
3.2. Rest assured I won't do anything like that again, anyways. All I'm
saying above is that when people pointed out the issues, they could've
helped fix them also. A fix would've included NOT using zpkg in the
final release which would have been perfectly ok with me.
Anyways, we're drifting into a what would have been if discussion
which is a bit pointless. I like that you
o Generate a release distribution.
It cannot be used as the basis for running developer sandboxes, at
least not without major hacking of the generated instances. Here is
a sample:
$ svn co $ZSVN/Zope3/branches/3.2 Zope-3_2-branch
...
$ cd Zope-3_2-branch
$ /path/to/python setup.py build_ext -i
You're missing another distutils command:
$ /path/to/python setup.py install_data --install-dir .
That's why it barfs below. I usually just type 'make' which does both.
...
$ /path/to/python utiltiies/mkzopeinstance.py -d /tmp/z32
...
$ cd /tmp/z32
$ bin/zopectl fg
...
ConfigurationError: ('Unknown directive',\
u'http://namespaces.zope.org/zope', u'role')
I don't think this is a useful place for us to be in Zope 3, and I
*don't* want to emulate Zope 3 in this direction in Zope
Re: [Zope3-dev] Re: RFC: The browser:page compromise
[EMAIL PROTECTED] wrote: what I like to see is something like: html metal:use-macro=macro:StandardMacros/page Such a macro could be lookuped by a ITALESExpression called *macro* similar to the IContentProvider implementation. The *StandardMacros* could be a mapping registred as a python factory. The *StandardMacros/page* knows how to lookup a registred macro called *page* in the *StandardMacros*. See also my (a little old) proposal at: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SimplifyMacroRegistration Note: the proposal is a little bit old and I whould change the directive browser:macros and make explicit use of a python factory rather then use a implicit mixin class. What do you think Philipp? This isn't part of the discussion about this proposal. Just to be clear: * Having to register macros as pages when they're not meant to be publishable sucks. * @@standard_macros sucks a bit too (too much indirection). It sure confuses people (like Tonico, as he says himself). * I'd rather not invent a new ZCML directive nor a new TALES expression type (I don't like this about viewlets and contentproviders). I could imagine a new traversal namespace: metal:macro use-macro=context/++macro++page / Here, 'page' is an adapter from (context, request) (it's a view) to IMacro or something. It will also be registered as such (as a view / or just an adapter /). I think viewlets and contentproviders should have taken the same road and used traversal namespaces. That's what they're for :). If we shall discuss this any further, I suggest we move into a separate thread. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
Balazs Ree wrote: On Sat, 22 Apr 2006 01:56:46 +0200, dev wrote: What I really dislike on the browser:page registration for macros, is, that such macros are also callable as traversable views rigth now. I whould like to see a different lookup for macros in the future. That was one of my first annoyances, when arriving as a total newcomer to the world of Z3. After asking a few of the smart guys, who said it is not possible to set this the way I wanted, I came up with a workaround of using a view class that overwrites __call__ and throws an exception from it. I'm using this since then but I don't like workarounds (not that it'd be such a bad one). IMO it would be great to solve this properly, because one point of using views is to have a fine control over what to publish and what not. And this is a bit broken at this point, currently. Right, that's why page templates that just provide macros should be registered unpublishable browser views and not browser pages. You see how far into the confusion the browser:page / directive has brought us? Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RE: RFC: The browser:page compromise
Hi Philipp -Original Message- From: Philipp von Weitershausen [mailto:[EMAIL PROTECTED] Sent: Saturday, April 22, 2006 9:15 AM To: [EMAIL PROTECTED] Cc: zope3-dev@zope.org Subject: Re: RFC: The browser:page compromise [EMAIL PROTECTED] 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). 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. 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? I don't by this as a improvment. 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 totaly ignore that Zope3 is not a experimental framework now and stability is also a criteria which should recognized. Please recognize that some people have built applications with zope3 since more then 2 years now. And respect that they are not willing to just change everything wich forces them to go other ways then before without a real *improvment*. btw, I don't dislike the refactoring at all, but I just dislike that we have to update our projects for *this* simplification. 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? Regards Roger Ineichen Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] RE: RFC: The browser:page compromise
Hi Philipp ZCML as of Zope 3.2 is inconsistent and to someone who's new and doesn't know every little detail from behind the scenes it's very obscure. And then it also makes debugging hard which has bitten me personally quite a few times. I explained this is a reply to Rocky Burt in this thread: http://mail.zope.org/pipermail/zope3-dev/2006-April/019169.html I don't telling that you are not right at all ;-) It's just not correct to remove the old way of doing. Now, would you rather make an attempt to document the inconsistent (and hard to maintain, not to forget!), or wouldn't you rather make an attempt at fixing the damn thing? I guess, making the refactoring and support a high level directive doing the old way will solve the problem. Regards Roger Ineichen Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: RFC: The browser:page compromise
Hi Philipp See also my (a little old) proposal at: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Simpl ifyMacroRegistration Note: the proposal is a little bit old and I whould change the directive browser:macros and make explicit use of a python factory rather then use a implicit mixin class. What do you think Philipp? This isn't part of the discussion about this proposal. Just to be clear: * Having to register macros as pages when they're not meant to be publishable sucks. * @@standard_macros sucks a bit too (too much indirection). It sure confuses people (like Tonico, as he says himself). * I'd rather not invent a new ZCML directive nor a new TALES expression type (I don't like this about viewlets and contentproviders). I could imagine a new traversal namespace: metal:macro use-macro=context/++macro++page / Here, 'page' is an adapter from (context, request) (it's a view) to IMacro or something. It will also be registered as such (as a view / or just an adapter /). I think viewlets and contentproviders should have taken the same road and used traversal namespaces. That's what they're for :). I don't think so. ITALESExpression are built for this use case. My context doesn't need to have a ++macro++ namespace! My context doesn't know about macros and viewlets. Macros or viewlets depend on context and request. This is the reason why we implemented a lookup via tales expression and not a traversal namespace on our context. If we shall discuss this any further, I suggest we move into a separate thread. Yup Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: RFC: The browser:page compromise
Hi Philipp IMO it would be great to solve this properly, because one point of using views is to have a fine control over what to publish and what not. And this is a bit broken at this point, currently. Right, that's why page templates that just provide macros should be registered unpublishable browser views and not browser pages. You see how far into the confusion the browser:page / directive has brought us? Yes, but this is only a problem how we lookup views/pages via /@@ in templates. The implementation of a *provider* tales expression for viewlet manager totaly avoids this :-) Regards Roger Ineichen Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: RFC: The browser:page compromise
[EMAIL PROTECTED] wrote: ZCML as of Zope 3.2 is inconsistent and to someone who's new and doesn't know every little detail from behind the scenes it's very obscure. And then it also makes debugging hard which has bitten me personally quite a few times. I explained this is a reply to Rocky Burt in this thread: http://mail.zope.org/pipermail/zope3-dev/2006-April/019169.html I don't telling that you are not right at all ;-) It's just not correct to remove the old way of doing. I won't maintain the old code. It's horrid. At some point we'll just have to clean out the attic. That's what deprecation is for. Timed removal. Allowing the old way for a while until it's removed. After all, you'll have one year to fix up your app. We recently agreed on this deprecation period in the community, if I may remind you... Now, would you rather make an attempt to document the inconsistent (and hard to maintain, not to forget!), or wouldn't you rather make an attempt at fixing the damn thing? I guess, making the refactoring and support a high level directive doing the old way will solve the problem. Not sure why you would want to do that. Have you read my proposal at all? Is this tiny base class SUCH a burden that you have to write another high-level directive? Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: The browser:page compromise
[EMAIL PROTECTED] wrote:
I think viewlets and contentproviders should have taken the
same road and used traversal namespaces. That's what they're for :).
I don't think so.
ITALESExpression are built for this use case.
I doubt that they were designed to *look up* things. They're
expressions, that means you enter some form of expression and the engine
will resolve the expression. Look at the expression types we had originally:
* path (resolve a/path/like/that)
* string (string ${templating})
* python (evaluate Python code)
In other words, TALES expressions *evaluate* some form of expression
(perhaps even regular expression, SQL, whatever). But using them to
*look up* something seems like abuse to me.
My context doesn't need to have a ++macro++ namespace!
It has ++view++, ++vh++, etc. namespaces. Why can't it have that namespace?
My context doesn't know about macros and viewlets.
Right. No one is expecting that. That's exactly what adapters are for.
Your context doesn't know about absolute URLs either, but yet we can say
context/@@absolute_url.
Macros or viewlets
depend on context and request. This is the reason why we implemented a
lookup via tales expression and not a traversal namespace on our context.
That's not a reason. Traversal namespaces also take context and request.
Lots of things take context and request.
Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: The browser:page compromise
[EMAIL PROTECTED] wrote: Hi Philipp IMO it would be great to solve this properly, because one point of using views is to have a fine control over what to publish and what not. And this is a bit broken at this point, currently. Right, that's why page templates that just provide macros should be registered unpublishable browser views and not browser pages. You see how far into the confusion the browser:page / directive has brought us? Yes, but this is only a problem how we lookup views/pages via /@@ in templates. That's how we lookup views. @@ is short for ++view++. Traversal namespaces are the way to lookup things that are not direct attributes. The implementation of a *provider* tales expression for viewlet manager totaly avoids this :-) As I said in another post, I think tales expressions are abused there. For looking up views, would you not use ++view++ but rather a view: TALES expression? Or for resources? I think not. Getting from an object to a view (=view,page,viewlet,etc.) of this object is traversal. It belongs into a traversal adapter. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: RFC: The browser:page compromise
Hi Philipp Yes, but this is only a problem how we lookup views/pages via /@@ in templates. That's how we lookup views. @@ is short for ++view++. Traversal namespaces are the way to lookup things that are not direct attributes. The namespace ++view++ is in the first line a namespace which makes it possible to use the same naming for ojects and views on a container. Second this is callable via the @@ in page templates. The implementation that we didn't use a tales expression is bad. It doesn't make sense to me that we can automaticly use traversal namespace in tales. I think the API for implement additional functionality is the ITALESExpression interface. Every other implementation which makes something possible in TAL is bad. That's just what I think. The implementation of a *provider* tales expression for viewlet manager totaly avoids this :-) As I said in another post, I think tales expressions are abused there. For looking up views, would you not use ++view++ but rather a view: TALES expression? Or for resources? I think not. Getting from an object to a view (=view,page,viewlet,etc.) of this object is traversal. It belongs into a traversal adapter. Yes, I know, but where doe we describe the interface for that? Is there a interface somewhere that I can see why I can call traversal namespace from TAL? Perhaps I missed this till now. How do you explain the TAL implementation of a @@ lookup to someone? Regards Roger Ineichen Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
[EMAIL PROTECTED] schrieb: The name browser for a namespace sux IMHO ;) The idea of a namspace called browser is the following: We use the namespace browser for *presentations* (the earlier name for pages) which depends on the IBrowserRequest. This is also reflected in the package structure like: package browser For other request types like FTPRequest, XMLRPC or JSON etc we use: package ftp xmlrpc json Perhaps this is to technical and will confuse people which don't know the base concepts of request type interfaces. But since no tehchnical peple have no chance to develope with z3 I think this naming is OK. At some point it will be necessary to make the framework understandable for normal UI designers or we'll stick with ugly user interfaces forever :) How is a browser defined in Zope 3 and how are these names related to it? [...] All of this directive are based on the IBrowserRequest. Other requests like FTPRequest don't have a menu layer etc. How is a BrowserRequest different from a HTTPRequest? Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
[EMAIL PROTECTED] schrieb: Hi Tonico At some point it will be necessary to make the framework understandable for normal UI designers or we'll stick with ugly user interfaces forever :) I think it's pretty clear right now. Do you really think if soembody don't understand what a folder json or browser should contain he ever will be able to understand what he has to do in ZCML? (I guess this is really not a naming problem) I once tried to understand how the default skin works -- after that I gave up the idea of creating a new ZMI skin myself. (Especially the MacroMagic was difficult to understand, but I want to try again someday). I like Philipps proposal because it tries to remove some of that magic that makes it often difficult to understand (or to accept) the concept. Do yo have a simpler naming and/or module/package structure concept in mind? If so, is this not only a part of a project or application like a CMS etc? Do you think UI Developers should work out of the box with a Zope3 instance? Not at the moment. A browser request offers a API for collecting browser (client) releated informations like charset settings. This is done via the interface IUserPreferredCharsets. Interesting, does it also offer an API for preferred language and preferred media? A browser request also deals with form data and collects the given form input into a FieldStorage object. The most important part here is that a browser request knows how to handle file upload. Interesting. The browser request is based on the http request which does the base stuff like cookie handling etc. Thanks for explanation. Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: RFC: The browser:page compromise
Yes, but speaking as another Zope3 learner, consistency and simplicity (is orthogonality a word?) of the model/API is extremely important too. I am in favor of such simplifying changes, as long as they are properly documented and deprecation is properly applied. For example: a deprecation warning telling me what I should do instead is great. There should be a link in the CHANGES.txt file to the original proposal for each change. If there is no time to update it after discussions take place, then why not cut and paste an excerpt from the relevant email thread into the CHANGES file? Or at a minimum how about a URL link to the start of the dev-list discussion thread. my 2c, --Craeg Kamal Gill wrote: Stability is especially important for those of us learning Zope 3, as well as those who offer Zope 3 training. I realize Z3 is a fast-moving target, but making existing books and documentation obsolete doesn't help the adoption of such a fantastic collection of software, IMO. - Kamal 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. Regards Roger Ineichen -- Kamal Gill - [EMAIL PROTECTED] http://www.adaptivewave.com Content Management Made Simple direct: +1.916.679.4123 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/cstrong%40arielpartners.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: RFC: The browser:page compromise
On Fri, Apr 21, 2006 at 01:03:58AM +0200, [EMAIL PROTECTED] wrote: Hi Philipp 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. FWIW, +1 on not changing the old directives. and +1 on introducing less magical directives and, eventually, deprecating and removing the old magical directives. -- Brian Sutherland Metropolis - it's the first movie with a robot. And she's a woman. And she's EVIL!! damm, I really need a new quote... ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: RFC: The browser:page compromise
Hi Tonico I once tried to understand how the default skin works -- after that I gave up the idea of creating a new ZMI skin myself. (Especially the MacroMagic was difficult to understand, but I want to try again someday). I see, I personaly like macros, but it is true, sometimes it is very hard to fit the pices to a big picture. Perhaps it whould help if we have another directive ;-) called browser:macro .. / which whould handle the macro registration rather then use browser:page ... /. This whould let us use some concept of a explicit *philiKON* factory for macro registrations which makes the standard_macros mapping a little more transparent. What I really dislike on the browser:page registration for macros, is, that such macros are also callable as traversable views rigth now. I whould like to see a different lookup for macros in the future. This could look like: Macro lookup right now: html metal:use-macro=context/@@standard_macros/page what I like to see is something like: html metal:use-macro=macro:StandardMacros/page Such a macro could be lookuped by a ITALESExpression called *macro* similar to the IContentProvider implementation. The *StandardMacros* could be a mapping registred as a python factory. The *StandardMacros/page* knows how to lookup a registred macro called *page* in the *StandardMacros*. See also my (a little old) proposal at: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SimplifyMac roRegistration Note: the proposal is a little bit old and I whould change the directive browser:macros and make explicit use of a python factory rather then use a implicit mixin class. What do you think Philipp? I like Philipps proposal because it tries to remove some of that magic that makes it often difficult to understand (or to accept) the concept. Do yo have a simpler naming and/or module/package structure concept in mind? If so, is this not only a part of a project or application like a CMS etc? Do you think UI Developers should work out of the box with a Zope3 instance? Not at the moment. A browser request offers a API for collecting browser (client) releated informations like charset settings. This is done via the interface IUserPreferredCharsets. Interesting, does it also offer an API for preferred language and preferred media? There is a adapter providing the interface IUserPreferredLanguages which can be used on requests. This adapter reads the request value *HTTP_ACCEPT_LANGUAGE* in the method *getPreferredLanguages*. The adapter is registred for the IHTTPRequest. A browser request also deals with form data and collects the given form input into a FieldStorage object. The most important part here is that a browser request knows how to handle file upload. Interesting. The browser request is based on the http request which does the base stuff like cookie handling etc. Thanks for explanation. no problem Regards Roger Ineichen Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
On Thu, 2006-20-04 at 18:56 +0200, Philipp von Weitershausen wrote: http://dev.zope.org/Zope3/TheBrowserPageCompromise 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 have a few naive comments/questions. Could you quickly explain in 2 lines or less what the difference between browser:page and browser:view is? To be frank, I've only ever used browser:page and its done what I wanted quite nicely from having class-less templates, and template-less classes, and classes+templates. The magic that you seem to describe is an implementation detail that I could care less about as a user of the functionality (perhaps if I were more involved with the coder underneath I would care more). So... having said all that, I have to say I don't see much benefit in what your RFC suggests but rather just a little added complication. - Rocky -- Rocky Burt AdaptiveWave - Content Management as a Service http://www.adaptivewave.com Content Management Made Simple ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
http://dev.zope.org/Zope3/TheBrowserPageCompromise
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 :)
- -1 on breaking ZCML in the wild. Propose *new* directives which have
new semantics, but for existing directives, we should clean up the
implementation rather than modifying semantics. E.g., we should be able
to rip out the gunk which synthesizes new classes in 'browser:page': I
think it derives from a period before we could assign a
'__Security_checker__' attribute to instances, and so *had* to have a
class in order to make the checker stuff work.
Here is an example from my 'pushpage' product, which has a directive for
registering pages using filesystem templates::
class PushPageFactory:
def __init__(self, template, mapper, checker=None):
if getattr(template, 'read', None) is not None:
template = template.read()
self.template = PushPageTemplate()
self.template.write(template)
self.mapper = mapper
self.checker = checker
def __call__(self, context, request):
page = PushPage(context, request, self.template, self.mapper)
if self.checker is not None:
page.__Security_checker__ = self.checker
return page
The directive handler instantiates the factory::
def pushpageViewDirective(_context,
for_,
name,
permission,
template,
mapping,
layer=IDefaultBrowserLayer,
):
Create and register factory for pushpage-driven views.
if for_ is not None:
_context.action(
discriminator = None,
callable = provideInterface,
args = ('', for_)
)
if permission == 'zope.Public':
permission = CheckerPublic
template = os.path.abspath(str(_context.path(template)))
if not os.path.isfile(template):
raise ConfigurationError(No such file, template)
required = {'__call__': permission,
'__getitem__': permission,
'browserDefault': permission,
'publishTraverse': permission,
}
checker = Checker(required)
factory = PushPageFactory(open(template, 'r'), mapping, checker)
_context.action(
discriminator = ('view', for_, name, IBrowserRequest, layer),
callable = handler,
args = ('provideAdapter',
(for_, layer), Interface, name, factory,
_context.info),
)
Note this implementation does not require majyk classes -- the factory
instances here function in place of the synthesize classes.
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFER8KA+gerLs4ltQ4RAh0kAJ9vvKtqAcPfZh0+2ujqpJefWGgsFQCeNzhi
r8E8Ewhpv/aJdP0t20vpZok=
=Z27s
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
Rocky Burt wrote: On Thu, 2006-20-04 at 18:56 +0200, Philipp von Weitershausen wrote: http://dev.zope.org/Zope3/TheBrowserPageCompromise 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 have a few naive comments/questions. Could you quickly explain in 2 lines or less what the difference between browser:page and browser:view is? Right now the difference is subtle. Too subtle, I'd say. With my proposal it'll be clearer :). A browser page is something that's published. It provides IBrowserPublisher and returns some data to the pbulisher that's in turn returned to the agent. A browser view is something more general. @@absolute_url is a browser view. It's never pulished (you wouldn't type into a browser http://.../some_obj/@@absolute_url). Rather, you use it from other components. To be frank, I've only ever used browser:page and its done what I wanted quite nicely from having class-less templates, and template-less classes, and classes+templates. The magic that you seem to describe is an implementation detail that I could care less about as a user of the functionality (perhaps if I were more involved with the coder underneath I would care more). It's not an implementation detail. After all, you're deciding whether to use a template or not. My goal is clarity in Python. So I'm writing a class which doesn't have *any* publishing information yet the pbulisher expects that. I can't just go in a test and say zope.component.provideAdapter(MyBrowserPageClass) currently and the page will be publishable (which is something different than just an adapter lookup). Why isn't it publishable? Because it doesn't have that functionality; browser:page / adds it magically in a dynamically created subclass. That sucks. By requiring browser page classes to implement IBrowserPublisher, all this will be more explicit. Of course, you can just use a convenient base class and simply implement a __call__ method. I think it'll be simpler and clearer what goes on with the proposal in place. So... having said all that, I have to say I don't see much benefit in what your RFC suggests but rather just a little added complication. The benefit is less magic in ZCML and more clarity in Python. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
Tres Seaver wrote: Philipp von Weitershausen wrote: http://dev.zope.org/Zope3/TheBrowserPageCompromise 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 :) -1 on breaking ZCML in the wild. Propose *new* directives which have new semantics, but for existing directives, we should clean up the implementation rather than modifying semantics. E.g., we should be able to rip out the gunk which synthesizes new classes in 'browser:page': I think it derives from a period before we could assign a '__Security_checker__' attribute to instances, and so *had* to have a class in order to make the checker stuff work. It's not only the security checker. It's the whole IBrowserPublisher implementation that's jerked into the subclass. My proposal is exactly stopping that. Of course, we can implement new directives (possibly with the same name but different namespace URI) and deprecate the old ones. But that's only marginally different from what I propose. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
On Thu, 2006-20-04 at 19:26 +0200, Philipp von Weitershausen wrote: A browser page is something that's published. It provides IBrowserPublisher and returns some data to the pbulisher that's in turn returned to the agent. A browser view is something more general. @@absolute_url is a browser view. It's never pulished (you wouldn't type into a browser http://.../some_obj/@@absolute_url). Rather, you use it from other components. Ok, this makes sense. But, the browser view you describe (something never published but still looked up from code and used) is exactly how I tend to use template-less browser:page's. By requiring browser page classes to implement IBrowserPublisher, all this will be more explicit. Of course, you can just use a convenient base class and simply implement a __call__ method. Hmm... sounds like you're making us do work. I'm all about making things more explicit and the like ... but if it means doing more work, perhaps we should think of a way that makes things more explicit without requiring more work :) The benefit is less magic in ZCML and more clarity in Python. +1 to this notion -- Rocky Burt AdaptiveWave - Content Management as a Service http://www.adaptivewave.com Content Management Made Simple ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
Rocky Burt wrote: On Thu, 2006-20-04 at 19:26 +0200, Philipp von Weitershausen wrote: A browser page is something that's published. It provides IBrowserPublisher and returns some data to the pbulisher that's in turn returned to the agent. A browser view is something more general. @@absolute_url is a browser view. It's never pulished (you wouldn't type into a browser http://.../some_obj/@@absolute_url). Rather, you use it from other components. Ok, this makes sense. But, the browser view you describe (something never published but still looked up from code and used) is exactly how I tend to use template-less browser:page's. That's why the difference wasn't clear in the past. It's not your fault, I'm blaming noone :). To give an example, the @@plone view should really be a browser:view, not a browser:page because it's never published. You don't type http://.../some_obj/@@plone into the URL bar of your browser. It wouldn't work anyways. By requiring browser page classes to implement IBrowserPublisher, all this will be more explicit. Of course, you can just use a convenient base class and simply implement a __call__ method. Hmm... sounds like you're making us do work. I'm all about making things more explicit and the like ... but if it means doing more work, perhaps we should think of a way that makes things more explicit without requiring more work :) I'm making you do a *little* bit more work. That doesn't mean you'll have to implement IBrowserPublisher from scratch all the time. Just inheriting from zope.publisher.browser.BrowserPage will be enough. That's what base classes are for, after all. Most people inherit from BrowserView currently anyways (I certainly encouraged that in my book), so they'd just have to change their base class. I consider an explicit base class an acceptable price for understanding what the heck is going on... Let me give you a small demonstration of the current magic and why it makes e.g. debugging so hard. Imagine you wonder why a certain view, let's say @@contents.html, resolves to something that you don't expect. So you try to debug: $ bin/zopectl debug from zope.publisher.browser import TestRequest request = TestRequest() root zope.app.folder.folder.Folder object at 0x2bfb330 from zope.component import getMultiAdapter getMultiAdapter((root, request), name=u'contents.html') zope.app.publisher.browser.viewmeta.Contents object at 0x2084e10 Now wtf is this object's class? You could look for it in the module stated but of course it's not there. This module is where it was dynamically assembled. Good luck finding the original implementation... Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: RFC: The browser:page compromise
Hi Philipp [...] I'll be fine with creating new directives instead of changing the old ones, if that's what the majority prefers. But then I'd very much like to see a Death Certificate for the old directives made out for some time in the future (doesn't have to be 2 releases, could be more). I don't like the proposal and the direction where you are Going, but this is another part. But I'm fine with this changes as long as the browser:page directive doesn't change in any way. Regards Roger Ineichen Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
Tres Seaver wrote:
- Introducing new deprecation warnings in third-dot releases is
probably inappropriate:
When we have we done this?
2.9.1 just did it (see below).
- Deprecating an API without cleaning up *all* core uses is a *lie*;
In some of the few cases where this happened was oversight and not
intentional. When you deprecate something, none of the core should still
use it. I think that's pretty clear.
Zope 2.9.0 shipped deprecating the OFS.content_types module without
removing all uses (I cleaned that up back in January).
Zope 2.9.1 deprecated zLOG without removing all uses: testrunner output
is *still* littered with deprecation warnings for zLOG. As far as I'm
concerned, that means 'zLOG' is *not* deprecated in the 2.9.x release
line, and may not therefore be ripped out unitl the appropriate interval
*after* 2.10 (i.e., in 2.12, not 2.11).
- Deprectaion of an older, stable alternative, *no matter how grotty,*
should go hand in hand with *lots* of confidence that the new favored
alternative really is superior, and by enough margin to make the
switch worthwhile. In my mind, this means that the new
implementation needs to be rolled out *in production* and tested in
the wild *before* we can deprecate the older alternative.
I think that's a big burden for refactorings. Under such a rule, Jim
wouldn't be allowed to roll out neither his adapter registry
improvements nor his Component Architecture simplification.
Refactorings *need* a bigger burden than we have recently been imposing:
- Doing a refactoring right means adding BBB code, which itself
increases the maintenance burden for core developers.
- As an example, the twisted server became the *default* in Zope 3.2
in spite of the fact that it broke ZEO because the developer who
landed the change doesn't use ZEO, and hence missed seeing the
damage.
- The packaging changes introduced in the 2.9 release cycle broke
usecases which many developers care about ('make inplace' is broken,
instance home testing broke, etc.) Worse, and ironically, the
breakage was incurred on behalf of 'zpkg', which is itself slated
(now) to be deprecated.
- Jim's current changes will most likely land for 2.10. If we don't
spend enough time in the beta cycle with them, we may be seeing
similar effects, or may need to be prepared to un-deprecate some
of the stuff currently on the doomed list.
We're not refactoring mercilessly. We're thinking about problems,
writing proposals, measuring risks, providing BBB and writing tests.
We'll have to trust our tests to a certain degree. If we don't then
perhaps we need more tests. We surely could use more functional tests.
I'll be fine with creating new directives instead of changing the old
ones, if that's what the majority prefers. But then I'd very much like
to see a Death Certificate for the old directives made out for some time
in the future (doesn't have to be 2 releases, could be more).
I don't think we are going to come to consensus about the appropirate
standard set of directives anytime soon: the current state of the
debate reminds me eerily of the lumbers vs splitters rift in the
world of paleoanthropology[1], which has been unresolved for more than a
generation now.
I stand by my claim that the reductionist strain in our current debate
is backed by developers who *also* admin the systems they have deployed,
and that this sample is not representative of the audience to whome Zope
is pitched.
[1] http://www.mos.org/evolution/downloads/desilva.html
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFER/Gj+gerLs4ltQ4RAu16AKDBkOGl3aoBIAVBQwUciAMwxRsUeQCfXv8u
7/D6eKGh5DO0uqJyvC5U1hU=
=tS58
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: The browser:page compromise
[EMAIL PROTECTED] wrote: I'll be fine with creating new directives instead of changing the old ones, if that's what the majority prefers. But then I'd very much like to see a Death Certificate for the old directives made out for some time in the future (doesn't have to be 2 releases, could be more). I don't like the proposal and the direction where you are Going, but this is another part. Not sure what you mean by that... But I'm fine with this changes as long as the browser:page directive doesn't change in any way. That confuses me even more. I *am* proposing changes to the browser:page directive... Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
Philipp von Weitershausen wrote: [EMAIL PROTECTED] wrote: I'll be fine with creating new directives instead of changing the old ones, if that's what the majority prefers. But then I'd very much like to see a Death Certificate for the old directives made out for some time in the future (doesn't have to be 2 releases, could be more). I don't like the proposal and the direction where you are Going, but this is another part. Not sure what you mean by that... But I'm fine with this changes as long as the browser:page directive doesn't change in any way. 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? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
Tres Seaver wrote:
Philipp von Weitershausen wrote:
Tres Seaver wrote:
- Introducing new deprecation warnings in third-dot releases is
probably inappropriate:
When we have we done this?
2.9.1 just did it (see below).
- Deprecating an API without cleaning up *all* core uses is a *lie*;
In some of the few cases where this happened was oversight and not
intentional. When you deprecate something, none of the core should still
use it. I think that's pretty clear.
Zope 2.9.0 shipped deprecating the OFS.content_types module without
removing all uses (I cleaned that up back in January).
Wow, that sucks.
Zope 2.9.1 deprecated zLOG without removing all uses: testrunner output
is *still* littered with deprecation warnings for zLOG. As far as I'm
concerned, that means 'zLOG' is *not* deprecated in the 2.9.x release
line, and may not therefore be ripped out unitl the appropriate interval
*after* 2.10 (i.e., in 2.12, not 2.11).
Yes, I was quite annoyed by that too. In fact, I'm a bit annoyed by some
weird deprecation warnings in Zope 2 (zLOG, ZClasses, some ZCatalog
index) that still exist! I know who added all of them, I can assure you,
it wasn't me...
- Deprectaion of an older, stable alternative, *no matter how grotty,*
should go hand in hand with *lots* of confidence that the new favored
alternative really is superior, and by enough margin to make the
switch worthwhile. In my mind, this means that the new
implementation needs to be rolled out *in production* and tested in
the wild *before* we can deprecate the older alternative.
I think that's a big burden for refactorings. Under such a rule, Jim
wouldn't be allowed to roll out neither his adapter registry
improvements nor his Component Architecture simplification.
Refactorings *need* a bigger burden than we have recently been imposing:
- Doing a refactoring right means adding BBB code, which itself
increases the maintenance burden for core developers.
- As an example, the twisted server became the *default* in Zope 3.2
in spite of the fact that it broke ZEO because the developer who
landed the change doesn't use ZEO, and hence missed seeing the
damage.
I guess we didn't have enough tests. Now we have a test that exercises
ZEO. Plus, we dealt with this problem before any final release (perhaps
even before the beta?). That's what alpha and beta phases are for...
- The packaging changes introduced in the 2.9 release cycle broke
usecases which many developers care about ('make inplace' is broken,
instance home testing broke, etc.) Worse, and ironically, the
breakage was incurred on behalf of 'zpkg', which is itself slated
(now) to be deprecated.
Forgive me if I'm a little rough on this subject, but here it goes:
I've had it with this whining about make inplace etc. It's been nearly
half a year since 2.9 is out and nobody has even made the attempt to fix
this so I guess nobody really needed it. Yet there's still whining. Yes,
I'm to blame for bringing zpkg to Zope 2 because the Zope 3.2 build
process strongly suggested it. If there were alternatives to zpkg,
nobody has suggested them and nobody seems to have explored them so far.
All I know is that everyone wanted Zope 3.2 in Zope 2.9 which is what
they got.
- Jim's current changes will most likely land for 2.10. If we don't
spend enough time in the beta cycle with them, we may be seeing
similar effects, or may need to be prepared to un-deprecate some
of the stuff currently on the doomed list.
We're not refactoring mercilessly. We're thinking about problems,
writing proposals, measuring risks, providing BBB and writing tests.
We'll have to trust our tests to a certain degree. If we don't then
perhaps we need more tests. We surely could use more functional tests.
I'll be fine with creating new directives instead of changing the old
ones, if that's what the majority prefers. But then I'd very much like
to see a Death Certificate for the old directives made out for some time
in the future (doesn't have to be 2 releases, could be more).
I don't think we are going to come to consensus about the appropirate
standard set of directives anytime soon: the current state of the
debate reminds me eerily of the lumbers vs splitters rift in the
world of paleoanthropology[1], which has been unresolved for more than a
generation now.
I'm not sure if this is a matter of what the standard set is or not.
browser:page / is a big pile of magic. See one of my replies to Rocky
Burt and the interpreter example. It makes code really really hard to debug.
I also think it makes it hard to understand. In response to this
proposal, several people have asked me By the way, what's the
difference between browser:page / and browser:view / anyhoo? That
alone has proven my point that the current system makes it absolutely
incomprehensible of what's going on behind the scenes.
I stand by my claim that
[Zope3-dev] RE: RFC: The browser:page compromise
Hi Philipp 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. Regards Roger Ineichen ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
Philipp von Weitershausen schrieb: I also think it makes it hard to understand. In response to this proposal, several people have asked me By the way, what's the difference between browser:page / and browser:view / anyhoo? That alone has proven my point that the current system makes it absolutely incomprehensible of what's going on behind the scenes. The name browser for a namespace sux IMHO ;) How is a browser defined in Zope 3 and how are these names related to it? addMenuItem addform containerViews defaultSkin defaultView editform form i18n-resource icon layer menu menuItem menuItems page pages resource resourceDirectory schemadisplay skin subMenuItem subeditform tool view viewlet viewletManager What is a page? Is a dynamic stylesheet or a dynamic javascript or an Atom feed a page? Does a page provide a mime_type? Should a page do content negotiation? Create a new clean namespace and call it user_interface (or ui)! :) Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: RFC: The browser:page compromise
Stability is especially important for those of us learning Zope 3, as well as those who offer Zope 3 training. I realize Z3 is a fast- moving target, but making existing books and documentation obsolete doesn't help the adoption of such a fantastic collection of software, IMO. - Kamal 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. Regards Roger Ineichen -- Kamal Gill - [EMAIL PROTECTED] http://www.adaptivewave.com Content Management Made Simple direct: +1.916.679.4123 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: RFC: The browser:page compromise
Hi Tonico -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tonico Strasser Sent: Friday, April 21, 2006 2:10 AM To: zope3-dev@zope.org Subject: [Zope3-dev] Re: RFC: The browser:page compromise Philipp von Weitershausen schrieb: I also think it makes it hard to understand. In response to this proposal, several people have asked me By the way, what's the difference between browser:page / and browser:view / anyhoo? That alone has proven my point that the current system makes it absolutely incomprehensible of what's going on behind the scenes. The name browser for a namespace sux IMHO ;) The idea of a namspace called browser is the following: We use the namespace browser for *presentations* (the earlier name for pages) which depends on the IBrowserRequest. This is also reflected in the package structure like: package browser For other request types like FTPRequest, XMLRPC or JSON etc we use: package ftp xmlrpc json Perhaps this is to technical and will confuse people which don't know the base concepts of request type interfaces. But since no tehchnical peple have no chance to develope with z3 I think this naming is OK. How is a browser defined in Zope 3 and how are these names related to it? addMenuItem addform containerViews defaultSkin defaultView editform form i18n-resource icon layer menu menuItem menuItems page pages resource resourceDirectory schemadisplay skin subMenuItem subeditform tool view viewlet viewletManager All of this directive are based on the IBrowserRequest. Other requests like FTPRequest don't have a menu layer etc. The exception zope:view doesn't use a implicit request this is the reason why the zope:view is also existent next to the browser:view. This means the zope:view directive can be used together with a different request then IBrowserRequest. What is a page? Is a dynamic stylesheet or a dynamic javascript or an Atom feed a page? Does a page provide a mime_type? Should a page do content negotiation? More or less all of this is a adapter called on a context and request providing a interface and a optional name producing a response ;-) Remember page is a replacement for the earlier name *presentation which was a little bit a to long naming. Create a new clean namespace and call it user_interface (or ui)! :) I think a name like ui doesn't reflect the request type and will be a bad idea for register *presentations* for json which are registred like jsonrpc:view ... / right now. But if you like to use ui:page / etc, you can do this by simply setting the namspace to: xmlns:ui=http://namespaces.zope.org/browser; And then use ui:page / btw, I whould like to use only one directive called *zope* for all directives. The directive *browser* is not really needed except for let us use zope:view and browser:view ;-) Regards Roger Ineichen Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: The browser:page compromise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
Tres Seaver wrote:
- Deprectaion of an older, stable alternative, *no matter how grotty,*
should go hand in hand with *lots* of confidence that the new favored
alternative really is superior, and by enough margin to make the
switch worthwhile. In my mind, this means that the new
implementation needs to be rolled out *in production* and tested in
the wild *before* we can deprecate the older alternative.
I think that's a big burden for refactorings. Under such a rule, Jim
wouldn't be allowed to roll out neither his adapter registry
improvements nor his Component Architecture simplification.
Refactorings *need* a bigger burden than we have recently been imposing:
- Doing a refactoring right means adding BBB code, which itself
increases the maintenance burden for core developers.
- As an example, the twisted server became the *default* in Zope 3.2
in spite of the fact that it broke ZEO because the developer who
landed the change doesn't use ZEO, and hence missed seeing the
damage.
I guess we didn't have enough tests. Now we have a test that exercises
ZEO. Plus, we dealt with this problem before any final release (perhaps
even before the beta?). That's what alpha and beta phases are for...
My point here is that the 'refactor mercilessly meme has left people
feeling free to make chnages of debatable value (Twisted is *still* not
accepted in the Zope community as a superiour choice for publishing
HTTP), without full weight being given to the needs of folks who aren't
up to their elbows in the code every day.
- The packaging changes introduced in the 2.9 release cycle broke
usecases which many developers care about ('make inplace' is broken,
instance home testing broke, etc.) Worse, and ironically, the
breakage was incurred on behalf of 'zpkg', which is itself slated
(now) to be deprecated.
Forgive me if I'm a little rough on this subject, but here it goes:
I've had it with this whining about make inplace etc. It's been nearly
half a year since 2.9 is out and nobody has even made the attempt to fix
this so I guess nobody really needed it. Yet there's still whining. Yes,
I'm to blame for bringing zpkg to Zope 2 because the Zope 3.2 build
process strongly suggested it. If there were alternatives to zpkg,
nobody has suggested them and nobody seems to have explored them so far.
All I know is that everyone wanted Zope 3.2 in Zope 2.9 which is what
they got.
Zope 3 is a *library* for Zope 2 -- I don't see any necessary reason to
have Zope 3's packaging model drive Zope 2's. What I recall about this
discussion was the following:
- There was distaste in the Zope 3 world for the carefully
hand-maintained code which made Zope 2's 'configure make make
install/inplace' dance work
- Jim proposed ripping it out in Zope 3 in favor of the generate
everything via zpkg' dance.
- In order to move toward the Zope 3 way, you proposed doing the
same for Zope 2.9.
- Immediately after you landed the change, folks began to point out
issues with it
o in-place builds were broken (the 'bin' directory was not created)
o out-of-tree builds broken (e.g.:
$ sudo mkdir /opt/zope29
$ sudo chown tseaver:root /opt/zope29
$ cd /opt/zope29
$ /path/to/zope29/checkout/configure make make inplace
o 'make instance' and 'mkzopeinstance' producing borked instances,
(since fixed for 2.9, but still broken in Zope 3)
- We stayed the course, and *today* are still stuck with a 2.9 branch
which *cannot be used* as the 2.8 branch was in a checkout. The
problem appears to be intractable, as the changes needed to make
'zpkg' work completely invalidated all our former experience and
knowledge of how to use a checkout tree.
Effectively, the only folks who can maintain the 'zpkg'-centric
build don't care about these usecases, and so we are stuck.
- Not only that, but we did it to support 'zpkg', which has proved to
be a failed experiment, even for packaging Zope 3. For instance,
at this point, a Zope 3.2 checkout tree can be uesd to do only:
o Run the unit tests.
o Generate a release distribution.
It cannot be used as the basis for running developer sandboxes, at
least not without major hacking of the generated instances. Here is
a sample:
$ svn co $ZSVN/Zope3/branches/3.2 Zope-3_2-branch
...
$ cd Zope-3_2-branch
$ /path/to/python setup.py build_ext -i
...
$ /path/to/python utiltiies/mkzopeinstance.py -d /tmp/z32
...
$ cd /tmp/z32
$ bin/zopectl fg
...
ConfigurationError: ('Unknown directive',\
u'http://namespaces.zope.org/zope', u'role')
I don't think this is a useful place for us to be in Zope 3, and I
*don't* want to emulate Zope 3 in this direction in Zope 2. I would
in fact be in
