[Zope3-dev] Re: Just introducing myself
Carl Lambert wrote: I've been getting this list for a few weeks now and i thought it was about time i introduced myself. Hi Carl and welcome to Zope3! The mailing list is a bit quiet so feel free to post questions. There often is a lag of a week or so in getting an answer, in my experience, but they usually come. I've been working with Zope 2.x for 4-5 years and Zope 3 for only 6 mos, and man, is it different! Lots of fun but also frustrating in figuring out how to do something. I've had to spend lots of time in the code, rather than inundating the mailing list with what are probably simple questions. Zope3 is at the early stages of significant documentation, IMHO, but we're doing our best to improve that. Earlier this year a new project dropped in my inbox and i decided zope would be the way forward, and with the release of zope3, I thought i would give it a try. So here i am, a zope novice, with a pretty big project and a mid october deadline. I'd be interested in hearing a brief overall description of the project, to see how it might fit into Zope3. I've racked up quite a few questions, but ill let you digest that lot first, (sorry it was so long) No problem, it wasn't that long. Glad you've found us - the community could use the fresh viewpoint. -Jeff ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] widgets for sources not yet complete?
On Apr 19, 2006, at 6:27 PM, Sam Stainsby wrote: From looking the Zope 3 code, I suspect that the full set of widgets is not yet available for sources. Yes, that is correct. Or have I got that wrong? I see there are some simpler widgets there that build the widgets used by vocabularies. I'm happy to try my hand at adding to that set of widget if nobody else is doing it. Go for it. Thanks Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] container preconditions inheritance
If I have a container interface IFoo with a __setitem__.precondition, and if IFoo inherits from IBar that also has one, shouldn't the inherited precondition also be checked by zope.app.container.constraints.checkObject? I don't see that in checkObject's code.. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RFC: The browser:page compromise
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 :) ___ 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] Ok to change PAU session credentials plugin?
Hello, I plan to change the PAU session credentials plugin to make it configurable in which form fields it looks for the credentials. My use case is that I want to use formlib to create a login form. formlib prepends form. at all IDs of the form fields. Therefore it is impossible to use these forms as login forms for that plugin (it's probably possible with some formlib subclassing but that introduces a lot effort). I don't see any negative aspects of this change. The values will default to the hard coded values that are used now, so now compatibility will be broken. Any objections? Florian ___ 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
Re: [Zope3-dev] RFC: The browser:page compromise
On 20.04.2006, at 18:56, 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 In the Proposal you say: Why is this a problem? Because certain behaviour is mixed into the class created on-the-fly. This behaviour is not apparent in our view class, yet we assume it exists. It's magic. For me this is not a reason to change/add directives. This just results in more work for keeping track with the zope3 releases in client-projects. It is ok to improve things, but this is no improvement for end users IMHO. This reminds me of the deprecation of the vocabulary directive, which is also just a burden for end users (i've missed that discussion). and: Browser pages are essentially just adapters to the Component Architecture. Implementation details (template or not, etc.) should not be of much interest during the registration. I don't think that the template is an implementation detail. IMHO For a high level user the adapters are an implementation detail. Regards, Bernd ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/zope- mailinglist%40mopa.at ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
