[Zope-dev] Re: Five and browser-oriented components
Hanno Schlichting wrote: Martijn Faassen wrote: Alexander Limi wrote: On Mon, 14 Apr 2008 10:11:11 -0700, Philipp von Weitershausen [EMAIL PROTECTED] wrote: *IF* you'd like to be pragmatic, I'd suggest we clean up those failing Plone tests, merge the branch and be on our way. This gets back to Hanno's suggestion of writing a clean test case that demonstrates this problem. We can then get it into Zope and fix it. This should allow cleaning up the Zope 3 integration in Zope 2 significantly. I kept my promise and added the simple tests for the first two issues I found while doing testing against Plone. Excellent, thank you very much! I hope this will motivate people to look into this branch again. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five and browser-oriented components
Alexander Limi wrote: On Mon, 14 Apr 2008 10:11:11 -0700, Philipp von Weitershausen [EMAIL PROTECTED] wrote: *IF* you'd like to be pragmatic, I'd suggest we clean up those failing Plone tests, merge the branch and be on our way. I'm also happy to make it visible on the Plone agenda, as long as it's made clear where the error is and what we have to fix. We all want this branch to land on trunk. :) This gets back to Hanno's suggestion of writing a clean test case that demonstrates this problem. We can then get it into Zope and fix it. This should allow cleaning up the Zope 3 integration in Zope 2 significantly. Then we can start experimenting with Zope 3-based *content* in Zope 2 too. http://faassen.n--tree.net/blog/view/weblog/2008/01/30/0 Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five and browser-oriented components
Martijn Faassen wrote: Alexander Limi wrote: On Mon, 14 Apr 2008 10:11:11 -0700, Philipp von Weitershausen [EMAIL PROTECTED] wrote: *IF* you'd like to be pragmatic, I'd suggest we clean up those failing Plone tests, merge the branch and be on our way. This gets back to Hanno's suggestion of writing a clean test case that demonstrates this problem. We can then get it into Zope and fix it. This should allow cleaning up the Zope 3 integration in Zope 2 significantly. I kept my promise and added the simple tests for the first two issues I found while doing testing against Plone. The third issue is more complex to reproduce in a simple way and has to do with NamedTemplateAdapters and their interaction with ViewPageTemplate files. I'll see if I can put together a unit tests for it this week as well. But for those interested in this, the first two tests should be a good start. I wrote down the technical details on this from my point of view to the list back in December. You can view that post at: http://mail.zope.org/pipermail/zope-dev/2007-December/030548.html Please ignore the horrendous code in that mail which I wrote out of despair back then. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five and browser-oriented components
Malthe Borch wrote: On Z2, certain imports need to come from Products.Five, to play nicely with ZPublisher and friends. Not really. You can inherit from zope.publisher.browser.BrowserView and Five's browser:page / directive will magically slap Acquisition.Explicit into a newly-created subclass that will be registered as a view. I'd like to ask for the motivation for not patching it onto the existing classes and/or modules. Because monkey-patches are evil. And I won't accept any buts here. They're just evil, hard-to-impossible to test and most important of all, absolutely unfathomable for the novice developer. The effect of having Z2-developers import from Products.Five is that they must opt out on packages that make use of templates, browser views, formlib, ... --- and it adds needless complexity. AFAIK, Plone already monkey patches formlib so you won't even have to change those imports. This split might also have prompted the Plone community to walk their own way to the extend that there isn't much code reuse outside of the core Zope packages (along with egg dependencies, but with our fake eggs, we're almost up to par here). I still believe the answer is my Acquisition + __parent__ patch. As mentionen in this thread already, it's several years old now (yikes!) but should merge quite cleanly, actually. Zope's own tests pass nicely, as do the CMF's, only Plone's tests fail in one or two places in an obscure way (and I'm talking about the whole ploneout testsuite here). *IF* you'd like to be pragmatic, I'd suggest we clean up those failing Plone tests, merge the branch and be on our way. Yes, we *might* be plastering over a potential problem in the patch, but the other tests didn't seem to be affected and intensive alpha and beta testing of that new Zope version would likely confirm or refute the existence of a serious problem. To be honest, my suspicion is that Plone is using some of the Five stuff in a way that it shouldn't be, hence causing a test failure with the cleaned up Five. Hanno removed some of the Five-raping procedures in Plone already, but there might be others lurking around and causing test failures. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five and browser-oriented components
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Martijn Faassen wrote: Technically, I think that this is going to be hard. You'd need to patch in the magic acquisition base class. Acquisition is the main reason that some of the code needed to be duplicated - without the existence of acquisition wrappers, security checks are not made for view access and things just won't work. I think if we could finish the philikon-aq_parent branch (or whatever it's called) that makes it possible to do acquisition using __parent__ pointers, we'd be a lot closer. AFAIU, that branch doesn't provide *acquisition* via the __parent__ pointer: No, it does. It makes __parent__ pointers completely equivalent to explicit acquisition wrappers. rather it allows the containment-based security check, which currently uses the 'inner' acquisition wrapper, to use the chain of '__parent__' pointers as an alternative when no acquisition wrapper is present. The security machinery (AccessControl) does an aq_aquire(obj, '__roles__') check. With __parent__ pointers, this will resolve properly. The branch is indeed ready from Zope's own point of view. Last thing I remember is that one (!) Plone tests fails in an obscure way. Then again, one failing test sometimes is enough :) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Five and browser-oriented components
Philipp von Weitershausen wrote: *IF* you'd like to be pragmatic, I'd suggest we clean up those failing Plone tests, merge the branch and be on our way. +1 - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Five and browser-oriented components
On Apr 14, 2008, at 19:11 , Philipp von Weitershausen wrote: *IF* you'd like to be pragmatic, I'd suggest we clean up those failing Plone tests, merge the branch and be on our way. +1 jens ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five and browser-oriented components
Philipp von Weitershausen wrote: *IF* you'd like to be pragmatic, I'd suggest we clean up those failing Plone tests, merge the branch and be on our way. Yes, we *might* be plastering over a potential problem in the patch, but the other tests didn't seem to be affected and intensive alpha and beta testing of that new Zope version would likely confirm or refute the existence of a serious problem. To be honest, my suspicion is that Plone is using some of the Five stuff in a way that it shouldn't be, hence causing a test failure with the cleaned up Five. Hanno removed some of the Five-raping procedures in Plone already, but there might be others lurking around and causing test failures. I'd be happy to help clean such things up on Plone trunk. I've been waiting for this branch for ges. :) I do remember Hanno saying he got an infite loop/segafult somewhere, which sounds more problematic. If we are pretty sure we won't get any of those, then I'd be very supportive of a merge. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five and browser-oriented components
On Mon, 14 Apr 2008 10:11:11 -0700, Philipp von Weitershausen [EMAIL PROTECTED] wrote: *IF* you'd like to be pragmatic, I'd suggest we clean up those failing Plone tests, merge the branch and be on our way. I'm also happy to make it visible on the Plone agenda, as long as it's made clear where the error is and what we have to fix. We all want this branch to land on trunk. :) -- Alexander Limi ยท http://limi.net ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five and browser-oriented components
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Martijn Faassen wrote: Technically, I think that this is going to be hard. You'd need to patch in the magic acquisition base class. Acquisition is the main reason that some of the code needed to be duplicated - without the existence of acquisition wrappers, security checks are not made for view access and things just won't work. I think if we could finish the philikon-aq_parent branch (or whatever it's called) that makes it possible to do acquisition using __parent__ pointers, we'd be a lot closer. AFAIU, that branch doesn't provide *acquisition* via the __parent__ pointer: rather it allows the containment-based security check, which currently uses the 'inner' acquisition wrapper, to use the chain of '__parent__' pointers as an alternative when no acquisition wrapper is present. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIAWdo+gerLs4ltQ4RAh/WAKCku3C7UKhJTYEr69f0qUzkgH8pQQCfbRo/ W1MlgpkUjjqovn12v1lgduc= =oSDG -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five and browser-oriented components
Malthe Borch [EMAIL PROTECTED] writes: On Z2, certain imports need to come from Products.Five, to play nicely with ZPublisher and friends. I'd like to ask for the motivation for not patching it onto the existing classes and/or modules. The effect of having Z2-developers import from Products.Five is that they must opt out on packages that make use of templates, browser views, formlib, ... --- and it adds needless complexity. IMO, any implicitness here will eventually slap you in your face, cause bugs, and be hard to figure out. I already dislike the way that e.g. FiveFormLibMixin implicitly changes my request to be more conform with formlib . This has caused confusion and pain for me in the past. Therefore, I'd argue that we should, in contrary to what you suggest, make the Zope 2 compatibility layer more explicit in the form of utility functions, instead of more implicit. Because it makes things more transparent and easier to debug. One concrete argument against patching the Zope 3 view page template in Five to be Zope 2 conform is that this would stand in the way of legitimate use of pure Zope 3 views in Zope 2 applications, which is something that's quite feasible today. We don't to lock ourselves into a situation where Z3 templates in Z2 assume that the view is acquisition wrapped. Daniel ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five and browser-oriented components
Daniel Nouri wrote: Therefore, I'd argue that we should, in contrary to what you suggest, make the Zope 2 compatibility layer more explicit in the form of utility functions, instead of more implicit. Because it makes things more transparent and easier to debug. You might be right; but it's a very bad place to be, stuck in the middle of two frameworks. We're duplicating code all over the place, and while this has obvious inherent qualities, it also wears us out as a community. I fail to understand why people are not more motivated to get rid of all the cruft. There are times when I wish the ship would sink, if only to get on with it. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five and browser-oriented components
Malthe Borch wrote: On Z2, certain imports need to come from Products.Five, to play nicely with ZPublisher and friends. I'd like to ask for the motivation for not patching it onto the existing classes and/or modules. Technically, I think that this is going to be hard. You'd need to patch in the magic acquisition base class. Acquisition is the main reason that some of the code needed to be duplicated - without the existence of acquisition wrappers, security checks are not made for view access and things just won't work. We do explicit acquisition in those bits of code, but it's still a pain and leads to confusion around self.context in views being acquisition-wrapped weirdly, breaking some expectations around aq_parent. The other argument against monkey-patching is that monkey-patching is something to be avoided if at all possible. I think it's wise to avoid it here, as it's possible. If you monkey-patched core Zope 3 classes, the chances are that you'll break Zope 3 code that assumes certain behavior. The way to get rid of many of these problems would be to get rid of the need for acquisition. Philipp started a branch long ago that allows the acquisition system to look at a __parent__ pointer if no acquisition wrapper is present. Since our views have __parent__ pointers, this should fix the issue. This branch has been lingering in an almost ready state for a long time now. In general, I think acquisition is one of the major remaining stumbling block in enabling quite a bit of straightforward Zope 3 code in Zope 2. Here are some more of my thoughts on this: http://faassen.n--tree.net/blog/view/weblog/2008/01/30/0 Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five and browser-oriented components
Malthe Borch [EMAIL PROTECTED] writes:
Daniel Nouri wrote:
Therefore, I'd argue that we should, in contrary to what you suggest,
make the Zope 2 compatibility layer more explicit in the form of utility
functions, instead of more implicit. Because it makes things more
transparent and easier to debug.
You might be right; but it's a very bad place to be, stuck in the
middle of two frameworks. We're duplicating code all over the place,
and while this has obvious inherent qualities, it also wears us out as
a community.
I think I found a useful pattern for how to work with z3c.forms to avoid
duplication. For each page that has forms, I make two views; one is the
Products.Five.BrowserView view that's looked up by the publisher and is
registered with ZCML. The other is my z3c.form.form.Form that does the
actual work and renders my content area. The relationship between these
two forms is similar to that of forms and subforms.
Here is an example of how this looks like in practice:
class MyForm(z3c.form.form.Form):
template = Z3ViewPageTemplateFile('form.pt')
fields = z3c.form.Fields(ISomething)
@button.buttonAndHandler(_('Apply'), name='apply')
def handle_apply(self, action):
data, errors = self.extractData()
# ...
class PloneView(Products.Five.BrowserView):
__call__ = Z2ViewPageTemplateFile('main.pt')
form = MyForm
def contents(self):
z2.switch_on(self)
return self.form(self.context.aq_inner, self.request)()
Here, main.pt is the part that renders main_template and pulls in
view/contents into the content area.
z2.switch_on() is a compatibility function that fiddles a bit with the
Zope 2 request to make it work with z3c.form (and also calls Five's
decodeInput).
Of course, PloneView is generic enough to be subclassed at this point:
class MyFunnyView(PloneView):
form = MyFunnyForm
What's the advantage of this separation?
- You don't have to worry about Acquisition in your form code, which
will make out the bigger part of your code. The implications of
Five's BrowserView being derived from Acquisition.Explicit has often
left me confused. (Death to self.context.aq_inner!)
- You can reuse form code between Zope 2 and Zope 3.
- Your forms can be rendered in any part of your page, like in
portlets.
- No subclassing of classes in z3c.form is necessary to use the forms
in Zope 2. (In contrast to Five's current way of subclassing
formlib.)
Daniel
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five and browser-oriented components
Martijn Faassen wrote: Technically, I think that this is going to be hard. You'd need to patch in the magic acquisition base class. Acquisition is the main reason that some of the code needed to be duplicated - without the existence of acquisition wrappers, security checks are not made for view access and things just won't work. I think if we could finish the philikon-aq_parent branch (or whatever it's called) that makes it possible to do acquisition using __parent__ pointers, we'd be a lot closer. Hanno and Philipp know more, but I think it's reasonably close. We do explicit acquisition in those bits of code, but it's still a pain and leads to confusion around self.context in views being acquisition-wrapped weirdly, breaking some expectations around aq_parent. And other bizarre things sometimes. The way to get rid of many of these problems would be to get rid of the need for acquisition. Philipp started a branch long ago that allows the acquisition system to look at a __parent__ pointer if no acquisition wrapper is present. Since our views have __parent__ pointers, this should fix the issue. This branch has been lingering in an almost ready state for a long time now. Ah, great minds think alike. ;) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five and browser-oriented components
Hi. Martin Aspeli wrote: Martijn Faassen wrote: Technically, I think that this is going to be hard. You'd need to patch in the magic acquisition base class. Acquisition is the main reason that some of the code needed to be duplicated - without the existence of acquisition wrappers, security checks are not made for view access and things just won't work. I think if we could finish the philikon-aq_parent branch (or whatever it's called) that makes it possible to do acquisition using __parent__ pointers, we'd be a lot closer. Hanno and Philipp know more, but I think it's reasonably close. It is reasonably close but as stated in some threads a few month back I hit some problems which I cannot solve (not even with walking up stack frames...). As the problems only showed themselves while doing browser testing inside Plone, I guess I can at least write some unit tests for them, so someone else can actually take a look at them more easily. I'll see if I can do that during my next 10% day [1] :) Hanno [1] http://www.jarn.com/blog/the-10-plone-manifesto ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five and browser-oriented components
Hanno Schlichting wrote: [snip] As the problems only showed themselves while doing browser testing inside Plone, I guess I can at least write some unit tests for them, so someone else can actually take a look at them more easily. I'll see if I can do that during my next 10% day [1] :) Yes, it'd be cool to have some tests that demonstrate the failure. Then come back to this list and bug people until they look into this. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
