Re: [Zope3-dev] Re: Zope Eggs
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan R. Yergler wrote: During the Zope3 sprint following PyCon, Paul and I, with Jim's guidance, began work on exploring how Zope can utilize eggs and be packaged using eggs. Since we're still experimenting with how eggs will be used, I wrote a script, zpkgegg, which reads the zpkg configuration information for a package and generates a standard setup.py from which an egg and vanilla sdist can be generated. You can find the script in subversion in the projectsupport project. For a brief overview of how the script is used, see README.txt (in http://svn.zope.org/projectsupport/trunk/src/zpkgegg/). The eggs generated by zpkgegg do not attempt to distinguish between runtime, testing or development dependencies, so almost all packages will want zope.testing. README.txt contains a brief example of how to point easy_install at the appropriate folders so that easy_install can resolve the dependencies. Note that at this point we're still experimenting with how we'll use eggs, so suggestions, feedback and comments are welcome. I've been playing around a lot, trying to get at least the eggs together to make ZPT usable outside of Zope (one of the original sprint goals). I have a couple of observations: 1. Putting 'setup.cfg' under version control sucks, because the 'develop' framework scribbles on it. I think we should do two things: - Move any special settings to a 'setup.cfg.in', and modify the workspace stuff to read that first when creating setup.cfg. - Make 'setup.cfg' a 'svn:ignore' file (at lest on the trunk). Agreed. IMO, we should either not scrible on setuop.cfg or not check it in. I vote for not scribbling on it. 2. Getting the development dependencies installed was harder than it seemed. Some packages (perhaps with help from a stanza in 'setup.cfg') could do that when running 'develop.py'; others needed me to run 'setup.py develop'. Maybe we should just kick off 'setup.py develop' at the end of the 'develop.py' dance? I suspect these are just lingering bugs. One thing I noticed, when I tried a few days ago was that zope.testing had a bogus dependency that made it's installation fail. ... 4. We need to begin creatinng released versions of the eggs (maybe numbering them according to the Z3 release they point into), and reorganizing the download page a bit (maybe development builds need to go on one page, and release builds on another). Why do you say this? I agree that we need this eventually, but it feels a bit early to me. Also, I expect and hope that many packages will have release cycles independent of Zope. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Shane Hathaway wrote: Jim Fulton wrote: Shane Hathaway wrote: +1. When I learn a skill, it is at first completely explicit, and as the skill becomes predictable and reliable, it gradually becomes implicit. If I kept everything explicit, I would hinder myself from building higher level skills. So explicit is better than implicit until a sufficiently tight abstraction comes about. Take memory management: yesterday it was explicit (malloc/free); today it's mostly implicit (garbage collection). Garbage collection is both an abstraction, since programmers no longer manage memory directly, and an indirection, since programmers now use APIs that call malloc and free. We all agree GC is good, so explicit is definitely not always better than implicit. Thanks for explaining Explicit is better than implicit, except when it's not. Admittedly, I should have posted that in my blog, not here. :-) I appreciated you making it explicit, Shane, even though I already knew and fully agree. :) I sometimes express this principle as magic is bad unless it's perfect magic. Do post it on your blog. Regards, Martijn ___ 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: SVN: Zope3/branches/jim-adapter/src/zope/ Redeprecated a number of things that didn't generate warnings
Philipp von Weitershausen wrote: Stephan Richter wrote: On Tuesday 14 March 2006 17:26, Philipp von Weitershausen wrote: The import doesn't, but the use of each method did because they looked like this: def getView(object, name, request, providing=Interface, context=None): if __warn__: warnings.warn( The concrete concept of a view has been deprecated. You want to use `getMultiAdapter((object, request), providing, name, context)`., DeprecationWarning, warningLevel()) ... I know for a fact that each call to getView, getResource, etc. (in short, every function that's now in back35.py) generated warnings upon being called, and it's the message shown above in the code snippet. This would also be the reason you would see many less deprecation warnings. Because here they would be only report the warning once for all getView calls, while the import approach reports every call. It's the other way around, but essentially yes. Fact is, the stuff in back35.py was definitely officially deprecated since Zope 3.1. I *think* we can get rid of it. You are right. They are now gone. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Martijn Faassen wrote: Shane Hathaway wrote: Jim Fulton wrote: Shane Hathaway wrote: +1. When I learn a skill, it is at first completely explicit, and as the skill becomes predictable and reliable, it gradually becomes implicit. If I kept everything explicit, I would hinder myself from building higher level skills. So explicit is better than implicit until a sufficiently tight abstraction comes about. Take memory management: yesterday it was explicit (malloc/free); today it's mostly implicit (garbage collection). Garbage collection is both an abstraction, since programmers no longer manage memory directly, and an indirection, since programmers now use APIs that call malloc and free. We all agree GC is good, so explicit is definitely not always better than implicit. Thanks for explaining Explicit is better than implicit, except when it's not. Admittedly, I should have posted that in my blog, not here. :-) I appreciated you making it explicit, Shane, even though I already knew and fully agree. :) I sometimes express this principle as magic is bad unless it's perfect magic. Do post it on your blog. Yes, it is a good thing to know, except that it is incomplete and obscures an important point. Magic always has the downside that it hides things. Often, as in the case of garbage collection, the benefit outweighs the cost. Too often though, people introduce magic (aka abstraction, indirection, automation) when the benefit doesn't justify the hiding. One should always approach magic with skepticism. This is an important design principle. The explicit is better than implicit is a guide, not a rule never to be broken. It's something we should start with. Does that mean we never provide automation? Of course not. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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: Zope Eggs
Agreed. IMO, we should either not scrible on setuop.cfg or not check it in. I vote for not scribbling on it. So right now we scribble the development dependencies as well as path (lib, script, etc) information into setup.cfg. The develop.py script reads the dependency information and attempts to install them into the specified lib directories. So it seems to make sense to put things like egg parameters, etc (settings independent of user workspace location) into setup.cfg.in, and then have develop.py populate a setup.cfg at runtime. I think we really do want a setup.cfg that isn't under version control -- storing the path information there makes the easy_install commands somewhat less verbose as you don't have to specify the script and lib locations each time you run. 2. Getting the development dependencies installed was harder than it seemed. Some packages (perhaps with help from a stanza in 'setup.cfg') could do that when running 'develop.py'; others needed me to run 'setup.py develop'. Maybe we should just kick off 'setup.py develop' at the end of the 'develop.py' dance? The one thing I can think of right now is that develop.py looks for it's dependency information in setup.cfg (as opposed to parameters to setup() for setup.py commands). So there is a potential duplication of information there that may make sense to get rid of. We looked at implementing develop.py as a distutils target (setup.py workspace, say), but ended up ditching it because our test implementation required setup.py to do something like : try: from foo import setup except ImportError: from distutils.core import setup (or something like that). Looking at that now, I suppose it's no worse than what we have to do now to support easyinstall. Would that be a better approach? Jim, have I forgotten another reason we dropped that approach? I have a near complete prototype of that approach lying around from the sprint. I suspect these are just lingering bugs. One thing I noticed, when I tried a few days ago was that zope.testing had a bogus dependency that made it's installation fail. Hmm... I didn't see any dependency information listed for zope.testing. Was that an egg you built or one downloaded from download.zope.org? ... 4. We need to begin creatinng released versions of the eggs (maybe numbering them according to the Z3 release they point into), and reorganizing the download page a bit (maybe development builds need to go on one page, and release builds on another). Why do you say this? I agree that we need this eventually, but it feels a bit early to me. Also, I expect and hope that many packages will have release cycles independent of Zope. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/nathanyergler%40gmail.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] what is ZCML?
Jim Fulton wrote: Martijn Faassen wrote: [snip] I appreciated you making it explicit, Shane, even though I already knew and fully agree. :) I sometimes express this principle as magic is bad unless it's perfect magic. Do post it on your blog. Yes, it is a good thing to know, except that it is incomplete and obscures an important point. Magic always has the downside that it hides things. Often, as in the case of garbage collection, the benefit outweighs the cost. Too often though, people introduce magic (aka abstraction, indirection, automation) when the benefit doesn't justify the hiding. One should always approach magic with skepticism. Agreed. That's why magic in software has a bad reputation. But it's not bad if it works almost invisibly. This is an important design principle. The explicit is better than implicit is a guide, not a rule never to be broken. It's something we should start with. Does that mean we never provide automation? Of course not. I suspect we're in a state of violent agreement here. :) What you say about this in part depends on who you're talking to. Repetition of code is generally bad. Many programmers don't abstract *enough* and copy paste code all over the place. We don't want to make them more wary of automation. To go to a related but slightly different topic: One form of abstraction I'm still grasping for in Zope 3 is support for coarse-grained components. When I have a whole bunch of (local) utilities, content objects, views, permissions and the like that work together, tied together with quite a bit of ZCML, I'd like to be able to reuse that more easily in an application. Right now the only way to reuse code like that I can find is to copy it and modify it, but that's wrong - it'd like to be able to use all that code from my application without having to copy or modify it. For instance, for an application I needed a user and group management system with a ZODB user interface. This uses the catalog, defines a number of content objects and adds a bunch of views. Extracting this functionality from the application turned out harder than I'd like it to be. And then I haven't figured out yet how to reuse it without having to copy and modify code... Are there patterns to do this in current Zope 3? Part of the problem is a dependency on local utilities - I believe the new local utility registration API you're working on should help there. For the rest, I guess I could just copy and rewire the ZCML, but that is quite a bit of work and failure-prone. I could also invent a ZCML statement with a much higher level of abstraction that takes the place of dozens of lower level statements, but people argue against this rather a lot. What other strategies could I employ? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/14/06, Lennart Regebro [EMAIL PROTECTED] wrote: OK, I just think I had a sort of brainwave-thingy, so I'm going to lay it out here to see if it was a good brainwave or not: Currently I can see three useful uses of ZCML: 1. User interface configurations, that is, everything that goes under browser. Menus, pages, forms, that sort of thing. 2. Switching on/overriding tools, utilities, adapters, etc. Call it component registration. 3. Making non-component classes into component classes. Now, one thing we notice here is that the things in 3 is not anything that needs to be overriden. It therefore doesn't HAVE to be in ZCML. You can do this equally well by making small wrapper classes in Python. Sidnei thinks this ZCML usage is good, I'm not convinced. This is one item that can be discussed. I also realised that what goes in my point 1 here, is what goes int Martijns #1, and what goes in my point to, fits into Martijns #2. So I would like to suggest that both view #1 and view #2 are equally valid, but for different things. One thing we notice is that for example the content directive doesn't fit vith view #2, of the leaner and meaner ZCML. And neither is it user interface configuration. My conclusion: It should go away. Thoughts on that? None, evidently. So it was a bad brainwave then. :) Ah well. Beware the Ideas of March, as my grandad never said. -- 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
Re: [Zope3-dev] Re: a new zcml directive?
Jim Fulton wrote: Philipp von Weitershausen wrote: Marius Gedminas wrote: I'd prefer from zope.annotation.adapter import AnnotationAdapter getFoo = AnnotationAdapter(for_=IBar, interface=IFoo, factory=Foo, key=FOO_KEY) # I suppose the key could be optional; you could use a dotted # interface name by default and then the ordinary zope:adapter factory=.foo.getFoo / +10 Likewise. I just tried to write AnnotationAdapter. Unfortunately, I haven't gotten very far yet, as it turns out I need to understand the internals of the implementation of the zope:adapter ZCML statement. zope:adapter has a bunch of automation to look for the interface of something and what it adapts on the factory. This works if the factory is the class itself, but in this case, the factory is a class which has instances which can provide an instance of the annotation class when called. So, I need to come up with trickery so that instances of AnnotationAdapter return the 'for_' argument when asked for by zope.interface.implementedBy() and the 'factory' argument when called with component.adaptedBy(). Since the instances of AnnotationAdapter are actually not doing any adaptation or implementing any of the interface, but are actually just providing a factory, it seems like this trickery would amount to actually lying. This is hairy enough for me to give up for now. Unless I'm missing something, I conclude that implementing AnnotationAdapter is currently at least as difficult as just implementing a new directive. The other conclusion is that figuring out what is happening in case something goes wrong is also at least as hard to understand as the innards of a directive, due to the trickery necessary to make it work. Using zope:adapter.. with an explicit 'for' and 'provides' would avoid the problem, but this seems to be going against the suggestions given in this thread. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Internal architecture or ZopeX3
Hi, because I hope I find ZopeX3 gurus in that forum, I'd like to know if there exists some documents on the internal structure /architecture of zope. I mean, I am looking for example for graphs like http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/ZopeArchitecture.stx/Figures/zopearchitecture.gif which shows the architecture of Zope2 in detail. What I'd like to know e.g. is how ZODB, content components, views are related. Are there any bridges? To sum up, I'd like to know, if there exists some more (internal) documentation on ZopeX3. Thanks a lot in advance! ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Martijn Faassen wrote: ... I suspect we're in a state of violent agreement here. :) Then why do people have to argue every single point ad nauseum? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Course-grained reuse.
Martijn Faassen wrote: ... One form of abstraction I'm still grasping for in Zope 3 is support for coarse-grained components. When I have a whole bunch of (local) utilities, content objects, views, permissions and the like that work together, tied together with quite a bit of ZCML, I'd like to be able to reuse that more easily in an application. Right now the only way to reuse code like that I can find is to copy it and modify it, but that's wrong - Right. it'd like to be able to use all that code from my application without having to copy or modify it. For instance, for an application I needed a user and group management system with a ZODB user interface. This uses the catalog, defines a number of content objects and adds a bunch of views. Extracting this functionality from the application turned out harder than I'd like it to be. And then I haven't figured out yet how to reuse it without having to copy and modify code... Are there patterns to do this in current Zope 3? Part of the problem is a dependency on local utilities - I believe the new local utility registration API you're working on should help there. For the rest, I guess I could just copy and rewire the ZCML, but that is quite a bit of work and failure-prone. I could also invent a ZCML statement with a much higher level of abstraction that takes the place of dozens of lower level statements, but people argue against this rather a lot. What other strategies could I employ? It's hard to comment without knowing the specifics. We do this sort of thing by registering the thing we want to reuse and then overriding bits as needed. I suspect that there are lots of little problems confounding you, including: - lack of worked out patterns in Zope 3 - lack of knowledge on your part - perhaps poor factoring in the things you are trying to reuse that makes your job more difficult. shrug I'll observe some open issues that I'm aware of: - You can't override subscriber registrations - We don't have a good way for installing collections of local components that work together. For our projects, we've used the generation machinery to automate this, but that only works if you want to install things in the root folder. I don't think high-level ZCML is the answer. It's possible that the new registration machinery will help (if I every find time to finish it). For example, perhaps you could define an assembly in a ZCML file and use that assembly as a base for one or more sites. Then you still need a way of dealing with persistent data. One thought I've had is that open connections should get registered as utilities and unregistered when they are closed. Then components registered globally could still get at databases within the context of a request at run time. I agree need some model for course-grained assemblies of components. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Course-grained reuse.
On Wednesday 15 March 2006 10:57, Jim Fulton wrote: It's possible that the new registration machinery will help (if I every find time to finish it). For example, perhaps you could define an assembly in a ZCML file and use that assembly as a base for one or more sites. I am waiting for the adapter work to be done to write a proposal for something like that. :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: what is ZCML?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Martijn Faassen wrote: Shane Hathaway wrote: Jim Fulton wrote: Shane Hathaway wrote: +1. When I learn a skill, it is at first completely explicit, and as the skill becomes predictable and reliable, it gradually becomes implicit. If I kept everything explicit, I would hinder myself from building higher level skills. So explicit is better than implicit until a sufficiently tight abstraction comes about. Take memory management: yesterday it was explicit (malloc/free); today it's mostly implicit (garbage collection). Garbage collection is both an abstraction, since programmers no longer manage memory directly, and an indirection, since programmers now use APIs that call malloc and free. We all agree GC is good, so explicit is definitely not always better than implicit. Thanks for explaining Explicit is better than implicit, except when it's not. Admittedly, I should have posted that in my blog, not here. :-) I appreciated you making it explicit, Shane, even though I already knew and fully agree. :) I sometimes express this principle as magic is bad unless it's perfect magic. Do post it on your blog. Yes, it is a good thing to know, except that it is incomplete and obscures an important point. Magic always has the downside that it hides things. Often, as in the case of garbage collection, the benefit outweighs the cost. Too often though, people introduce magic (aka abstraction, indirection, automation) when the benefit doesn't justify the hiding. One should always approach magic with skepticism. This is an important design principle. The explicit is better than implicit is a guide, not a rule never to be broken. It's something we should start with. Does that mean we never provide automation? Of course not. I wonder if there isn't a sore spot which is driving a lot of the discussion here, but isn't being mentioned: the experiment in form definition (browser:addform / browser:editform). The interesting thing about that experiment is that it *almost* worked, as magic; its failure was not in what it made easier (generating a view from a schema *and* a policy), but in what it made harder (changing the behavior of the generated view). Developers who are the only admins for the sites they deploy are *not* representative of the intended audience for ZCML; they are much more comfortable with back to Python as a solution than more traditional admins / integrators would be. Big directives, with clearly documented knobs for specifying policies, are likely to appeal more to folks sho are *not* inclined to write Python. The fact that such developer-admins are the primary users of ZCML so far is due to the small size of the Zope3 market to date. 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 iD8DBQFEGD5f+gerLs4ltQ4RAnCjAKDb/6AM4phxLZhHnSPH554Ysv8CIwCfRIUo 8+DrkkvhQFQDB8WGCSC70j4= =X/7J -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: Zope Eggs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan R. Yergler wrote: During the Zope3 sprint following PyCon, Paul and I, with Jim's guidance, began work on exploring how Zope can utilize eggs and be packaged using eggs. Since we're still experimenting with how eggs will be used, I wrote a script, zpkgegg, which reads the zpkg configuration information for a package and generates a standard setup.py from which an egg and vanilla sdist can be generated. You can find the script in subversion in the projectsupport project. For a brief overview of how the script is used, see README.txt (in http://svn.zope.org/projectsupport/trunk/src/zpkgegg/). The eggs generated by zpkgegg do not attempt to distinguish between runtime, testing or development dependencies, so almost all packages will want zope.testing. README.txt contains a brief example of how to point easy_install at the appropriate folders so that easy_install can resolve the dependencies. Note that at this point we're still experimenting with how we'll use eggs, so suggestions, feedback and comments are welcome. I've been playing around a lot, trying to get at least the eggs together to make ZPT usable outside of Zope (one of the original sprint goals). I have a couple of observations: 1. Putting 'setup.cfg' under version control sucks, because the 'develop' framework scribbles on it. I think we should do two things: - Move any special settings to a 'setup.cfg.in', and modify the workspace stuff to read that first when creating setup.cfg. - Make 'setup.cfg' a 'svn:ignore' file (at lest on the trunk). Agreed. IMO, we should either not scrible on setuop.cfg or not check it in. I vote for not scribbling on it. I'd rather not check it in, myself. Even if the 'develop.py' helper doesn't scribble, it is a natural place for the developer to scribble. Generating it when needed, and ignoring it for version control, seems healthier to me. Perhaps we should use a different strategy for released packages than trunk ones? 2. Getting the development dependencies installed was harder than it seemed. Some packages (perhaps with help from a stanza in 'setup.cfg') could do that when running 'develop.py'; others needed me to run 'setup.py develop'. Maybe we should just kick off 'setup.py develop' at the end of the 'develop.py' dance? I suspect these are just lingering bugs. One thing I noticed, when I tried a few days ago was that zope.testing had a bogus dependency that made it's installation fail. ... 4. We need to begin creatinng released versions of the eggs (maybe numbering them according to the Z3 release they point into), and reorganizing the download page a bit (maybe development builds need to go on one page, and release builds on another). Why do you say this? I agree that we need this eventually, but it feels a bit early to me. I think that getting the eggs usable outside of Zope is a goal, and one which makes getting the packages released more urgent than simply changing Zope to use them (which won't happen until November at the earliest). Many of the packages are actually very stable, and could easily be released now, assuming some elbow grease is applied. Also, I expect and hope that many packages will have release cycles independent of Zope. That will require that they get maintainers who actively manage them. One sign of such a package is that it has its own CHANGES.txt file, and that its bugfix / feature entries end up there, rather than in Zope's changelog. For the time being, I'll be content with packages which merely point into the release tag area of Zope. 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 iD8DBQFEGEBg+gerLs4ltQ4RArzYAKDNkq4C4JTPaloz3qu/C1p8s3A0BwCgw9f/ r+ZGtDI1V5Zv9KkjcSOY5+0= =FZXB -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: Coarse-grained reuse.
Jim Fulton wrote: Martijn Faassen wrote: ... [coarse grained component reuse] Are there patterns to do this in current Zope 3? Part of the problem is a dependency on local utilities - I believe the new local utility registration API you're working on should help there. For the rest, I guess I could just copy and rewire the ZCML, but that is quite a bit of work and failure-prone. I could also invent a ZCML statement with a much higher level of abstraction that takes the place of dozens of lower level statements, but people argue against this rather a lot. What other strategies could I employ? It's hard to comment without knowing the specifics. I realize this. I'm grasping to describe even what I would like to be able to do. The specific are unfortunately quite diverse and scattered across content code, utilities, ZCML, view code, etc. We do this sort of thing by registering the thing we want to reuse and then overriding bits as needed. I suspect that there are lots of little problems confounding you, including: I suspect so too, along with just not having a clear picture of what the ideal solution should even look like. - lack of worked out patterns in Zope 3 - lack of knowledge on your part - perhaps poor factoring in the things you are trying to reuse that makes your job more difficult. I think all three are true. I have enough knowledge to attempt to amend my lack of knowledge (and experience) and the lack of factoring in my code by, among other things, discussing this here. It's something I've been thinking about on and off for a while now. I'm also trying to see the patterns that would help here. shrug I'm quite keen to make progress in this myself. :) I'll observe some open issues that I'm aware of: - You can't override subscriber registrations Not something that I've had to worry about yet. - We don't have a good way for installing collections of local components that work together. For our projects, we've used the generation machinery to automate this, but that only works if you want to install things in the root folder. Right. So far what we've done is some setup code to: * create utilities in the application's site object * create indexes in the catalog we just set up. * create some content objects that come with the application into the site object (typically folder-like things that will contain the actual content the user creates) Especially for the first two cases using custom Python code feels wrong. It'd be better if there was some framework this custom Python code could be registered with. I'm not thinking about the registration stack stuff, but at least some way to register Hey, this code wants to install stuff into a site somewhere, so that in my application I can use that. What it's doing is a bit like a factory, but it's different in that: * it's not just creating a single object. * what's created is going to be stuffed into an existing object. I see you say something quite similar when you talk about 'assemblies' below. That's a good word. I don't think high-level ZCML is the answer. I don't see a way out through ZCML yet either. As I said, I'm just grasping for patterns. It's possible that the new registration machinery will help (if I every find time to finish it). For example, perhaps you could define an assembly in a ZCML file and use that assembly as a base for one or more sites. Yes, to give feedback on the pattern: I think that could be useful. Then you still need a way of dealing with persistent data. One thought I've had is that open connections should get registered as utilities and unregistered when they are closed. Then components registered globally could still get at databases within the context of a request at run time. Hmm, what if your utility is already local and uses the ZODB as an integral part of itself, such as the intid service a catalog with indexes? Would they need to be rewritten to work with this pattern? I agree need some model for course-grained assemblies of components. I think this would indeed be a major step in the right direction for my troubles. I think there are other issues as well, but this is one of the larger hurts I'm feeling. As to the other issues, I will think about ways to articulate them better. Regards, Martijn ___ 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: a new zcml directive?
Jim Fulton wrote: Martijn Faassen wrote: ... I just tried to write AnnotationAdapter. Unfortunately, I haven't gotten very far yet, as it turns out I need to understand the internals of the implementation of the zope:adapter ZCML statement. No, you don't. zope:adapter has a bunch of automation to look for the interface of something and what it adapts on the factory. This works if the factory is the class itself, but in this case, the factory is a class which has instances which can provide an instance of the annotation class when called. This may not be documented as well as it should be, but not for lack of trying. 1. You can always provide the interface provided by an adapter when you register it. I realize this, but I was trying to implement the example as suggested, also because it's clear that the tendency is away from specifying 'for' and 'implements' in ZCML. I know I wouldn't have a problem if I use 'for' and 'implements' in ZCML. 2. If a factory declares that it implements a single interface, then you can omit the interface when registering the adapter. If a factory is a class, it typically declares that it implements an interface via the implements call in the class statement. Well, I found this out by reading the code in zope.app.component. If a factory is not a class, and if it allows attributes to be set on it, then the interface.implementor function can be used to make declarations for it. This is documeted in zope/interfaces/README.txt and zope/component/README.txt. This is one bit I was missing, thanks. Unfortunately I read in zope/interface/README.txt that the 'implementer' function cannot be used for classes yet, so this will change the design somewhat (I was using __call__, looks like I'll have to exploit lexical scoping and generate a function on the fly). Using implements() on the class seems like lying, as the class is just implementing a factory, not the functionality itself. Besides, I'd have to change the class each time it gets called (it's using implementedBy to check). Then that leaves convincing 'adaptedBy()'. One hack is to write the 'for_' argument that's passed to the AnnotationAdapter() constructor directly to an attribute called __component_adapts__. I don't think I can use 'adapts()' on a lexically scoped function... I stand by my conclusions on this approach sounding simple in theory, but still being a bit harder than it should be in practice. :) Regards, Martijn ___ 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: a new zcml directive?
Martijn Faassen wrote: Jim Fulton wrote: ... If a factory is not a class, and if it allows attributes to be set on it, then the interface.implementor function can be used to make declarations for it. This is documeted in zope/interfaces/README.txt and zope/component/README.txt. This is one bit I was missing, thanks. Unfortunately I read in zope/interface/README.txt that the 'implementer' function cannot be used for classes yet, so this will change the design somewhat (I was using __call__, looks like I'll have to exploit lexical scoping and generate a function on the fly). No. You can use it on an instance of the class. You want something like: class FactoryFactory: def __init__(self): # initialize a new factory ... implementer(self, someinterfacethatmyinstancesimplement) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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: a new zcml directive?
Jim Fulton wrote: Martijn Faassen wrote: Jim Fulton wrote: This is one bit I was missing, thanks. Unfortunately I read in zope/interface/README.txt that the 'implementer' function cannot be used for classes yet, so this will change the design somewhat (I was using __call__, looks like I'll have to exploit lexical scoping and generate a function on the fly). No. You can use it on an instance of the class. You want something like: class FactoryFactory: def __init__(self): # initialize a new factory ... implementer(self, someinterfacethatmyinstancesimplement) I'm stupid. Right! Then this and the __component_adapts__ hack should be enough to make it work (still an unpleasant hack, that). With that I suspect I should even be able to steal the implementedBy and the adaptedBy from the annotation itself, which would mean I'd only need to spell it out there. Thanks again! Martijn ___ 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: a new zcml directive?
Martijn Faassen wrote: ... Then this and the __component_adapts__ hack should be enough to make it work (still an unpleasant hack, that). Huh? Use adapter. class FactoryFactory: def __init__(self): # initialize a new factory ... implementer(self, someinterfacethatmyinstancesimplement) zope.component.adapter(theinterfacemyinstancesadapt) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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: a new zcml directive?
Jim Fulton wrote: Martijn Faassen wrote: ... Then this and the __component_adapts__ hack should be enough to make it work (still an unpleasant hack, that). Huh? Use adapter. class FactoryFactory: def __init__(self): # initialize a new factory ... implementer(self, someinterfacethatmyinstancesimplement) zope.component.adapter(theinterfacemyinstancesadapt) Another one that I couldn't find but is indeed there, sorry. It's right there in the zope.component README.txt with an example: def personJob(person): ... return getattr(person, 'job', None) personJob = interface.implementer(IJob)(personJob) personJob = component.adapter(IPerson)(personJob) Okay, that's one step closer to support for this in the annotation package, thanks! In the new world for ZCML, ZCML as a language falls apart in a minimalistic XML language, and some support code (such as zope.app.annotation.AnnotationFactory) to help it do more advanced things. One remaining benefit of higher-level ZCML is that it gets picked up by apidoc and thus can be discovered fairly easily by developers as part of the configuration story. While AnnotationFactory is doing definition and is in Python code in the new world for ZCML, this act of definition is closely associated with the act of registering it in ZCML. It would be nice if we somehow retained discoverability for APIs that are meant to work with ZCML - it's obvious from this subthread that it takes some idiots^H^H^H^H^H^Hpeople a while to pick up an API... We'd like people working with annotations to be able to find out that we have this available. Perhaps a README.txt in the annotation package is enough for now, though. Perhaps we can think of other ways to help make this discoverable... Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote: Martijn Faassen wrote: ... I suspect we're in a state of violent agreement here. :) Then why do people have to argue every single point ad nauseum? Because we want to understand the current decisions and thinking. I never intend to argue, but email is such a poor discussion medium that the words often come out sounding like an argument. The statement explicit is better than implicit, except when it's not is void of any meaning. I think I know what it means, but I can only guess what you think it means. I attempted to elaborate so you can confirm or deny a common understanding. I don't think I elaborated enough, though. It seems to be a fundamental principle for building Zope 3, so we all need to understand it the same way. Back on topic, the message I'm hearing about ZCML is confusing: high level configuration is good, but ZCML isn't going to handle it because we want to limit the number of directives. Does that mean we're going to use Python code to generate ZCML? (That's a rhetorical question... I think.) Shane ___ 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: a new zcml directive?
On 3/15/06, Martijn Faassen [EMAIL PROTECTED] wrote: In the new world for ZCML, ZCML as a language falls apart in a minimalistic XML language, and some support code (such as zope.app.annotation.AnnotationFactory) to help it do more advanced things. That's what I'd like to see! :) One remaining benefit of higher-level ZCML is that it gets picked up by apidoc and thus can be discovered fairly easily by developers as part of the configuration story. While AnnotationFactory is doing definition and is in Python code in the new world for ZCML, this act of definition is closely associated with the act of registering it in ZCML. I agree with that benefit of higher-level ZCML. But I've found in practice that documentation is still terse and sparse. That alone is what has had me digging into the code to try to figure out ok, what does that mean? name - TextLine (default = None) Name Adapters can have names. This attribute allows you to specify the name for this adapter. So, yay for documentation. That bit's good. But things like this could really really benefit from some examples. Especially on core things like adapter, whose 'locate', 'permission', and 'trusted' properties and their impact on each other are a bit tricky to figure out. But Python code and interfaces get picked up by apidoc too. Well, most of them (schema fields have gone missing in action.. I think a search will turn them up, but they can't be browsed to directly). One of the biggest downsides of higher-level ZCML to me is that it feels totally disconnected from Python. The documentation, as it stands now, generally documents the fields. But it doesn't go into what's being done behind the scenes, or why I should be using directive X, or how to use the results of directive X. The other downside is that higher level ZCML needs the ZCML 'runtime' in order to work. Besides, AnnotationFactory isn't just associated with registering something in ZCML. It can be associated with registering something with:: zope.component.provideAdapter(...) I know that the adapter directive does a bit more than just provide an adapter. But the point is that it could be used outside of ZCML. It would be nice if we somehow retained discoverability for APIs that are meant to work with ZCML - it's obvious from this subthread that it takes some idiots^H^H^H^H^H^Hpeople a while to pick up an API... We'd like people working with annotations to be able to find out that we have this available. Perhaps a README.txt in the annotation package is enough for now, though. Perhaps we can think of other ways to help make this discoverable... I don't know the status of the static-apidoc tool, but maybe that could help in some ways... By having http://api.rubyonrails.com/ , not only is there a great online API reference, but it's (of course) searchable by the search engine of choice. Hopefully there will be a day when a search for 'zope annotations' will have the API reference and a couple of darn good recipes/articles/tips as the first set of results. I know it's been helpful to see a reference to something in Rails and google ``rails validates_presence_of`` and usually get to the api reference first. (Not that I'm leaving Zope for Rails, but I have been toying with it a bit, I admit). -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Shane Hathaway wrote: ... Back on topic, the message I'm hearing about ZCML is confusing: That's because we don't all agree. high level configuration is good, but ZCML isn't going to handle it because we want to limit the number of directives. Does that mean we're going to use Python code to generate ZCML? (That's a rhetorical question... I think.) What I've said is that ZCML should be about configuration, especially registration, and *not* about defining things. I've said things should be defined in Python and registered in ZCML. I don't necessarily have a problem with high-level configuration directives that configure several things at once, although I'm wary that the benefit would be worth the obscurity. I'd also like to acknowledge Tres' point about high-level non-Python definition mechanisms for things like forms and schemas. I agree with him that such facilities could be a good thing. I may disagree with him on whether these should be ZCML. I definately don't think that they should be. Finally, I'll note that I've used the term high-level configuration to refer to the things we have sysadmins edit when they install Zope systems. We currently use ZConfig for this. I don't think ZCML (or any other XML-based system) should be used for this. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote: I'd also like to acknowledge Tres' point about high-level non-Python definition mechanisms for things like forms and schemas. I agree with him that such facilities could be a good thing. I may disagree with him on whether these should be ZCML. I definately don't think that they should be. it depends a lot on the availability of softwares and of standards used to create such definitions. Julien has done some work on using XML schemas in zope3 as you know: http://blogs.nuxeo.com/sections/blogs/julien_anguenot/2005_08_19_xml-schema-support-on http://svn.nuxeo.org/trac/pub/browser/z3lab/zope/xmlschema/trunk/demo/ XForms could be a good choice for defining forms too. I'm using JSON for MVC definitions, because they can be used in Javacript without much fuss. YAML seems to be easy to read too, etc. SVG can be investigated too for defining layouts, graphical objects etc. this is really an area where one should look to see what already exists. sorry if I'm off-topic. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote: Finally, I'll note that I've used the term high-level configuration to refer to the things we have sysadmins edit when they install Zope systems. We currently use ZConfig for this. I don't think ZCML (or any other XML-based system) should be used for this. Ok. The high-level configuration I'm thinking about is somewhere in between. I don't know what to call it, so I won't call it anything. Here's what has happened to me several times: I'm a Python developer, writing simple code for Zope 3, and I follow Stephan's examples on how to develop content types for Zope 3. I write simple schema-based classes and simple directives. I've been conditioned to not repeat myself in code; in fact, breaking that rule gives me a sick feeling. So I proceed to follow Stephan's examples, which involves writing similar ZCML directives for multiple classes. The repetitious classes don't bother me because I know how to refactor them. But the ZCML I've written gives me a sick feeling, because I don't know how to refactor ZCML. The sick feeling doesn't go away, so I get scared of Zope 3. Then I come here, hoping to find comfort. I would feel more comfortable if one of the following things were to happen: 1. The group acknowledges that repetition in ZCML is bad. 2. Someone shows me how to avoid repetition in ZCML. 3. We decide that ZCML is a failed experiment. 4. We decide that ZCML should gain more qualities of a high level language. 5. We solve this some other way. I recognize that #3 and #4 are very risky, and we've already been over the risks, but I include them because they still feel better than the status quo. I can't help but wonder if ZCML is largely a reaction to the horrible initialize(context) methods in CMF products. Those beasts are horrible because they are based on workarounds of workarounds. The workarounds came about because we were more willing to add code than fix code. That attitude prevailed because we didn't have automated tests of Zope. Now that we have automated tests, programmers are more likely to fix code rather than add code, so we can expect to see very few workarounds, so initialize(context) garbage won't happen. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Lennart Regebro wrote at 2006-3-14 21:17 +0100: On 3/14/06, Dieter Maurer [EMAIL PROTECTED] wrote: Aspect orientation does this: Use a given unprepared implementation and add all kinds of aspects to them: logging, tracing, persistence, additional checks Yeah. And that aspect orientation is in Zope3 done in ZCML... So I don't really know what you are trying to say here. :-) I reject Sidnei's claim Zope3 were unique in this respect (apart from using ZCML, of course) :-) -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote at 2006-3-15 07:29 -0500: ... Magic always has the downside that it hides things. Often, as in the case of garbage collection, the benefit outweighs the cost. Too often though, people introduce magic (aka abstraction, indirection, automation) when the benefit doesn't justify the hiding. One should always approach magic with skepticism. Neither costs nor benefits are objective but subjective. For me, when I repeat the same sequence for about half a dozen of times, I am crying out for an abstraction (if possible with a well chosen name) that gets rid of the repetition. I am rarely interested in details and am happy when lots of them are hidden -- that's no cost but benefit. Well chosen names give me enough feeling about the overall effect that I rarely need to dig into the details. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
Shane Hathaway wrote: Jim Fulton wrote: Finally, I'll note that I've used the term high-level configuration to refer to the things we have sysadmins edit when they install Zope systems. We currently use ZConfig for this. I don't think ZCML (or any other XML-based system) should be used for this. Ok. The high-level configuration I'm thinking about is somewhere in between. I don't know what to call it, so I won't call it anything. Here's what has happened to me several times: I'm a Python developer, writing simple code for Zope 3, and I follow Stephan's examples on how to develop content types for Zope 3. I write simple schema-based classes and simple directives. I've been conditioned to not repeat myself in code; in fact, breaking that rule gives me a sick feeling. So I proceed to follow Stephan's examples, which involves writing similar ZCML directives for multiple classes. The repetitious classes don't bother me because I know how to refactor them. But the ZCML I've written gives me a sick feeling, because I don't know how to refactor ZCML. The sick feeling doesn't go away, so I get scared of Zope 3. Then I come here, hoping to find comfort. Could you give a more specific example? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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: what is ZCML?
On 3/15/06, Tres Seaver [EMAIL PROTECTED] wrote: I wonder if there isn't a sore spot which is driving a lot of the discussion here, but isn't being mentioned: the experiment in form definition (browser:addform / browser:editform). The interesting thing about that experiment is that it *almost* worked, as magic; its failure was not in what it made easier (generating a view from a schema *and* a policy), but in what it made harder (changing the behavior of the generated view). Isn't that always the case though? Besides - I don't think there's anything more vague than the concept of 'policy'. What policy? Where did it come from? Who wrote it? In what? Anyways, I don't mind if someone wants 'browser:addform' as an add-on. But I don't think those things belong in the core. If someone wants to make a package that lets them build a web site using nothing but ZCML to glue a bunch of crap together! then lets have it. But not in the core. It's limiting. It's restrictive. The bit that it makes hard is the bit that most people get to at some point in the lifecycle of their web application. Why make them switch paradigms at that point? ZCML can only carry people so far. And we can only push it so far (if that's the path we follow) before it starts developing the needs for more programming language type features like full expressions. I say we cut it down to size now. Developers who are the only admins for the sites they deploy are *not* representative of the intended audience for ZCML; they are much more comfortable with back to Python as a solution than more traditional admins / integrators would be. Big directives, with clearly documented knobs for specifying policies, are likely to appeal more to folks sho are *not* inclined to write Python. But the developers have to write the ZCML for their products. That's the current story. The bigger and weirder and harder that universe becomes, the less likely that the developers are going to actually use it 'correctly'. Initial experiments with viewlets and content providers were the first things that proved the flaws of browser:page versus browser:view. In browser:view you can specify a 'provides' attribute. It becomes very useful when you want to allow for viewlets to show up or not show up for certain pages. It's a powerful feature of extensibility and integration, I think, to support viewlets/content providers. But if developers don't know that: (a) Any implements() statement on their view class is likely to be ignored. (b) Only browser:view (and zope:view) allow specifying a provided interface that a viewlet or content provider can match against. browser:page does not. (c) Writing for viewlets and in small code / small fragments (and using the update/render paradigm in general) is the easiest way to make the interface extensible. That makes the integrators job much harder. If browser:view, browser:page, and zope:view all went away today in favor of subclassing from formlib.Page, BrowserView, or something else common that provided the core full-view-page pieces (publishTraverse, browserDefault, __call__) and only zope:adapter was used as the ZCML directive, it would be much easier (I think) to start providing views that can be better augmented by integrators. (Besides, I think 'integrators' are better served by the programming language. Anyone who thinks they can just download a bunch of random components and build a unique web site with nothing but XML is deluding themselves). Administrators (if we're talking about system administrators) may be better served by tools and components that expose certain configuration options to ZConfig (or whatever might replace it), along with the tools to generate the skeletons for that. RDBMS connections, tag blacklists if you will, whatever. I don't see anything in the current ZCML that actually makes it obvious from downloading and installing Product X (especially if installing means checking out from subversion or unpacking a .tgz) which elements in it need special configuration like - which mail server to use, which MySQL login to use, etc. Instead the ZCML is full of content, adapter, utility, browser:* directives, most of which are essential to that package or application. You may not want to custom configure 95% of that stuff. Most of that's just to load the application up into Zope. If there's a tag blacklist or RDB connection or other hypothetical administrative feature, it's buried amongst all of the developer stuff anyways. There's no nicely commented file like the default Zope 2 ZConfig file that details all of the options, why they're there, how to change them. Instead it's 500 lines of code registering 27 views, 14 menu items, and a nice chinchilla. How does that ZCML benefit an administrator or integrator that you feel must be protected from all of the Python code? Don't you think that, to an outsider, digging for:: viewlet name=kbase.importzipform
Re: [Zope3-dev] what is ZCML?
Jim Fulton wrote: Shane Hathaway wrote: Jim Fulton wrote: Finally, I'll note that I've used the term high-level configuration to refer to the things we have sysadmins edit when they install Zope systems. We currently use ZConfig for this. I don't think ZCML (or any other XML-based system) should be used for this. Ok. The high-level configuration I'm thinking about is somewhere in between. I don't know what to call it, so I won't call it anything. Here's what has happened to me several times: I'm a Python developer, writing simple code for Zope 3, and I follow Stephan's examples on how to develop content types for Zope 3. I write simple schema-based classes and simple directives. I've been conditioned to not repeat myself in code; in fact, breaking that rule gives me a sick feeling. So I proceed to follow Stephan's examples, which involves writing similar ZCML directives for multiple classes. The repetitious classes don't bother me because I know how to refactor them. But the ZCML I've written gives me a sick feeling, because I don't know how to refactor ZCML. The sick feeling doesn't go away, so I get scared of Zope 3. Then I come here, hoping to find comfort. Could you give a more specific example? My attempt to solve the PyWebOff challenge, which I posted here: http://mail.zope.org/pipermail/zope3-users/2006-March/002608.html The ZCML I wrote in that message is quite representative of the ZCML I wrote for a Zope 3-based system that's now in production. (The system is a management interface for a Beowulf-style microfilm scanning cluster.) The repetition isn't a showstopper, obviously, but it makes me feel bad, so Zope 3 ends up being no fun. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/15/06, Dieter Maurer [EMAIL PROTECTED] wrote: I reject Sidnei's claim Zope3 were unique in this respect (apart from using ZCML, of course) :-) I think that amongst web app frameworks we are. I don't know of any other aspect oriented ones. I could be wrong. -- 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
Re: [Zope3-dev] Re: Coarse-grained reuse.
On 3/15/06, Martijn Faassen [EMAIL PROTECTED] wrote: Jim Fulton wrote: - We don't have a good way for installing collections of local components that work together. For our projects, we've used the generation machinery to automate this, but that only works if you want to install things in the root folder. Right. So far what we've done is some setup code to: * create utilities in the application's site object * create indexes in the catalog we just set up. * create some content objects that come with the application into the site object (typically folder-like things that will contain the actual content the user creates) Especially for the first two cases using custom Python code feels wrong. It'd be better if there was some framework this custom Python code could be registered with. I'm not thinking about the registration stack stuff, but at least some way to register Hey, this code wants to install stuff into a site somewhere, so that in my application I can use that. What it's doing is a bit like a factory, but it's different in that: I think I understand what you're saying. I run this pattern a lot myself. To date, I've used the event handler approach to catch when my site is added. But also, to date, I've stuffed a lot of the setup code into a single function called by the event handler. I don't think there's anything wrong with custom Python code to set this up. It's programmatic, isn't it? A lot of it may be repetitive, and if that's the case, functions/methods can help. Are we all just so used to writing big long blocks of code in Zope 2 Python Scripts that we've forgotten we can do this? I'm trying to abstract some common Bottlerocket patterns out into new base framework/library for my company to use, and this is actually one of them. I was trying to come up with something last night for just this issue. Basically, I thought of writing a couple of interfaces that would do something *like* zope.app.generations, but instead of being a 'database opened' event response, used to automatically patch persistent data with the expectations of code, these things would work on a 'site added' event. What I didn't spend any time thinking about was whether to have future upgrades go through this tool, or through generations. Anyways, I was thinking this would be done through adapters. For just handling install, I was thinking of something like ISiteConfigurator. Maybe a marker interface of ISiteConfigurable would be used for a 'site' to be registered with a built in event handler - although you could write your own event handler and call the configurator yourself. ISiteConfigurator would just have one method, 'configure'. In there, you do what you want. There would be a 'SiteConfiguratorBase' class offered (but not required) that would provide helper methods like 'ensureUtility' - things to take away the repetitiveness of the current registrations. But it would be you (developer of the 'site') that would decide what gets installed, and how. Sometimes, there are very common things that have to be installed. But sometimes, it's very specific. IntIds is very straightforward. A catalog requires setting up its indexes. Setting up pluggable auth can require quite a bit of work, depending on all of the pluggable auth bits you need. So it obviously can't all be automated with a bunch of one liners. The system, as I see it, is nothing grandiose. It's just something that I hope will solve (for us) the problem of: * Having and maintaining (and copying and pasting) the same event handler to every app. * Having to remember some of the specifics of basic registration. If we have a site that builds on another site, we could also subclass from its adapter and provide any extended install features, or even selectively ignore them. The wins are: * Using an adapter to bind the configurator to the site allows the 'framework' to handle when and how the configuration gets run for a particular site / added object, but doesn't worry about what it does. * Use the wonders of object oriented technology to provide a base class with helpful methods for the common configuration chores. * Use this same wonder to allow common sites to share common tasks for establishing local utilities. * Still have the power to be as programmatic as needed, which can ensure that the utilities are established in a proper order and deal with specific situations regarding their establishment. Or just to handle dealing with very repetitive situations in an easier fashion. Maybe something like that is what Jim's talking about in regards to assemblies? ZCML really can't handle this. Not unless the ZCML in question was basically a pointer to a callable object, at which point you've got an event handler all over again. I'm looking at my code to set up the authentication utility for some of our sites. Very specific rules about what plugins are needed (users, groups, http credentials) and things in those
Re: [Zope3-dev] Re: a new zcml directive?
Martijn Faassen wrote: I stand by my conclusions on this approach sounding simple in theory, but still being a bit harder than it should be in practice. :) I think this is pretty simple: def makeAnnotationAdapter(for_, factory, key): @zope.component.adapter(for_) @zope.interface.implementer(IAnnotations) def annotationAdapter(context): annotations = IAnnotations(context) try: return annotations[key] except KeyError: ob = factory() annotations[key] = ob # to please security... zope.app.container.contained.contained( ob, context, 'foobar-whatever') return ob return annotationAdapter getFoo = makeAnnotationAdapter(IFoo, Foo, FOO_KEY) Perhaps I'm missing something?!? Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
