[Zope3-dev] Re: Internal architecture or ZopeX3
Further I'd like to know, what happens to ZPT at runtime. Are they compiled into Python modules? Thanks ___ 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: [snip] 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 share these sentiments. Not that I have a particularly sick feeling (I've been immunized by too much exposure? :) but because I'm grasping for ways, patterns, to make my code look better, briefer, shorter, less repetition, more reuability. I would feel more comfortable if one of the following things were to happen: 1. The group acknowledges that repetition in ZCML is bad. I definitely acknowledge his one. 2. Someone shows me how to avoid repetition in ZCML. Grasping around here myself. We need to show more people than just Shane and Martijn too - we need to be able to reach a wider audience if this is going to work. 3. We decide that ZCML is a failed experiment. On the one hand, I'm not willing to do that. On the other hand, if ZCML is to be a simple registration language, I am starting to idly wonder why a bunch of CSV tables wouldn't do (and might not be clearer and simpler). If ZCML is to be a simple registration language, I'd also like there to be a 1 to 1 mapping of ZCML statement to Python code. Right now there is a mapping and while it may be reasonably straightforward, I personally am still lost in APIs (and it looks like Jeff Shell is too). This learning curve should be smaller. Whatever we do, if ZCML is to be replaced we need to replace it with something. I think many of the notions of ZCML are dead on - this registration shouldn't be happening in normal Python code mixed with the rest but as a separate activity. It should allow overriding. It should be amenable to analysis. 4. We decide that ZCML should gain more qualities of a high level language. I personally am quite interested in exploring this, but I'd like to see some examples of what this would actually look like, concretely. 5. We solve this some other way. This would be satisfactory too. :) 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. We can mitigate some of the risks of both #3 and #4 as we could do them as separate, experimental, non-Zope projects. I can't help but wonder if ZCML is largely a reaction to the horrible initialize(context) methods in CMF products. In non-CMF Silva we also got horrible initialize(context) methods, and we've got horrible and long install.py files. When looking at ZCML we should clearly keep in mind that what it replaces. Silva's install.py expressed in ZCML would be preferrable to what we have now in most ways. 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. And because we weren't as good at designing good Pythonic APIs as we are now. At least I've definitely gotten better at that over the last years. 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. I'm not convinced of this, myself. If Zope 3 becomes popular, lots of application developers won't be using automated tests in Zope 3 code either. In addition, you get unnecessary workarounds because people fail to see the right way to do it and are in a hurry. I feel that a declarative and domain specific language can help in such cases. 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: Coarse-grained reuse.
Jeff Shell wrote: 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? Writing Python code for setup is very handy, but we've also seen where it went wrong in Zope 2. Writing Python code for setup therefore worries me. What's the Zope 3 idea on this? It used to be simple: we had ZCML for such things. But when I started using Zope 3 ZCML turned out to be insufficient from the start for this activity, so I used Python code (with an event hooked up to the site add event, too). And now, ZCML is not going to be used for some of this anymore, so I become less certain. Where I think just using Python code starts going wrong (potentially) is when I want to combine my setup Python code with your setup Python code to build a larger application. I'd like there to be common patterns so there's at least a reasonable chance that you can plug my TTW UI for user management into your application without having to rewrite large parts of either. I'd also like this pattern to be there when I'm *writing* my larger application, so I say, 'okay, this is all for TTW user management' then, and then more easily extract it later. 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. This may be in the direction of a solution. I haven't studied generations in detail, myself. Anyway, any such solution needs to be in the common codebase, otherwise we're going to end up with a lot of custom ones. [snip design ideas] * 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. I think ordering may become important eventually. I.e. I can only install my Foo thing into a site if Baz is already installed. I'd think I'd like to be able to express such ordering in some declarative way. 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 plugins
Re: [Zope3-dev] Re: a new zcml directive?
Philipp von Weitershausen wrote: 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?!? It's not as simple as your code actually doing to what it needs to do. :) It doesn't do what it needs to do as we're not aiming to implement IAnnotations here, but whatever the factory is implementing. I also would like to avoid having to specify for_, as the factory should already specify this information. But it's definitely simpler, if, as you do, know the zope.interface and zope.component APIs, and how various things can be used as decorators. I hadn't used them yet. Yesterday I had something that worked if I specified both 'for' and 'implements' in ZCML; it was pretty close to what you had without the decorator bits. I modified it today using your decorator idea and it appears to work now: def factory(factory, name, key): @zope.component.adapter( list(zope.component.adaptedBy(factory))[0]) @zope.interface.implementer( list(zope.interface.implementedBy(factory))[0]) def getAnnotation(context): annotations = IAnnotations(context) try: return annotations[key] except KeyError: result = factory() annotations[key] = result zope.app.container.contained.contained( result, context, name) return result # Convention to make adapter introspectable # (XXX where is this used? is this necessary at all?) getAnnotation.factory = factory return getAnnotation You can use this with the following Python code and ZCML: class MyAnnotation(Persistent): implements(interfaces.IFoo) adapts(interfaces.IBaz) getMyAnnotation = annotation.factory(MyAnnotation, 'my_annotation', 'some_key') adapter factory=.module.getMyAnnotation trusted=yes / I hope I can still make the requirement for name and key go away. In many ways this behaves very similarly to the adapter ZCML directive (as I did peek at its implementation :). I realize I may be in the minority on this particular mailing list, but to me the implementation of this code wasn't pretty simple. If this is the way we are going to encourage people to build higher level abstractions for definition, we may lose some of them. 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: Philipp von Weitershausen wrote: 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?!? It's not as simple as your code actually doing to what it needs to do. :) It doesn't do what it needs to do as we're not aiming to implement IAnnotations here, but whatever the factory is implementing. I also would like to avoid having to specify for_, as the factory should already specify this information. But it's definitely simpler, if, as you do, know the zope.interface and zope.component APIs, and how various things can be used as decorators. I hadn't used them yet. Yesterday I had something that worked if I specified both 'for' and 'implements' in ZCML; it was pretty close to what you had without the decorator bits. I modified it today using your decorator idea and it appears to work now: def factory(factory, name, key): @zope.component.adapter( list(zope.component.adaptedBy(factory))[0]) @zope.interface.implementer( list(zope.interface.implementedBy(factory))[0]) def getAnnotation(context): annotations = IAnnotations(context) try: return annotations[key] except KeyError: result = factory() annotations[key] = result zope.app.container.contained.contained( result, context, name) return result # Convention to make adapter introspectable # (XXX where is this used? is this necessary at all?) getAnnotation.factory = factory return getAnnotation You can use this with the following Python code and ZCML: class MyAnnotation(Persistent): implements(interfaces.IFoo) adapts(interfaces.IBaz) getMyAnnotation = annotation.factory(MyAnnotation, 'my_annotation', 'some_key') adapter factory=.module.getMyAnnotation trusted=yes / I hope I can still make the requirement for name and key go away. In many ways this behaves very similarly to the adapter ZCML directive (as I did peek at its implementation :). I realize I may be in the minority on this particular mailing list, but to me the implementation of this code wasn't pretty simple. If this is the way we are going to encourage people to build higher level abstractions for definition, we may lose some of them. Regards, Martijn Hi, excuse me, but can someone explain what problem the pattern / workaround is supposed to fix, does it create and return a default annotation value in case an annotation key does not exist? shouldn't the annotation machinery be fixed instead to provide getAnnotation(..., default=...) ? /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] Re: a new zcml directive?
Jean-Marc Orliaguet wrote: [snip] excuse me, but can someone explain what problem the pattern / workaround is supposed to fix, does it create and return a default annotation value in case an annotation key does not exist? shouldn't the annotation machinery be fixed instead to provide getAnnotation(..., default=...) ? I thought I described it in my initial post. I was looking for a way to register annotations for objects (and create them if they aren't there yet) without having to write fairly long bits of code for each annotation factory. I just want to be able to say: myannotation = IFoo(obj) where IFoo is the interface of an annotation of the obj. The only place I worry about it being an annotation is in the registration code. No need to import anything else from that package. Whether it needs to create a new annotation or get an existing one is an implementation detail. 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: Jean-Marc Orliaguet wrote: [snip] excuse me, but can someone explain what problem the pattern / workaround is supposed to fix, does it create and return a default annotation value in case an annotation key does not exist? shouldn't the annotation machinery be fixed instead to provide getAnnotation(..., default=...) ? I thought I described it in my initial post. I was looking for a way to register annotations for objects (and create them if they aren't there yet) without having to write fairly long bits of code for each annotation factory. I just want to be able to say: myannotation = IFoo(obj) where IFoo is the interface of an annotation of the obj. The only place I worry about it being an annotation is in the registration code. No need to import anything else from that package. Whether it needs to create a new annotation or get an existing one is an implementation detail. Regards, Martijn OK, basically you mean that the 'annotations' given in your original post should implement a 'setdefault' method? regards /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Internal architecture or ZopeX3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhold Strobl wrote: Further I'd like to know, what happens to ZPT at runtime. Are they compiled into Python modules? No, they are compiled into bytecodes exceuted by the TAL interpreter, which is invoked when the template is rendered. 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 iD8DBQFEGXYZ+gerLs4ltQ4RAn+7AJ93hl5bvHkgwi4IZdzZQGoemuqMvQCfXsDF xj4Cw0mt6zN+oQQKCbQCEEA= =QEM0 -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: a new zcml directive?
Jean-Marc Orliaguet wrote: [snip] OK, basically you mean that the 'annotations' given in your original post should implement a 'setdefault' method? I don't see how that would help - you'd still end up writing a factory that uses the setdefault, right? I don't want to keep repeating factory code each time I want to do this, including factory code that calls IAnnotations(), uses setdefault() or anything else. I just want to say, I want to make an adapter that uses this standardized factory code. How the factory code does this is not very interesting, it's just that I don't want to keep writing it over and over. 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: Coarse-grained reuse.
On 3/16/06, Martijn Faassen [EMAIL PROTECTED] wrote: Jeff Shell wrote: 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? Writing Python code for setup is very handy, but we've also seen where it went wrong in Zope 2. Writing Python code for setup therefore worries me. What's the Zope 3 idea on this? It used to be simple: we had ZCML for such things. But when I started using Zope 3 ZCML turned out to be insufficient from the start for this activity, so I used Python code (with an event hooked up to the site add event, too). And now, ZCML is not going to be used for some of this anymore, so I become less certain. Where I think just using Python code starts going wrong (potentially) is when I want to combine my setup Python code with your setup Python code to build a larger application. Then you write a third batch of Python code that further tweaks, removes, or adds to what the combination of the first two do. This is only kindof setup. ZCML, again, is registering very very very core things. Like in Formulator's initialization code: set up the registries, register the core fields. That doesn't stamp out a form. When I build a Knowledge Base site, I'm going to need X and Y and Z in order to use it. I'm going to need each of those to be configured according to how I designed the knowledge base. Python gives me the best option for automating that, because it is (in a way) a kind of business logic: I'm indexing on these fields, I'm building Extent catalogs on these, uh, extents, I'm setting up groups and roles for user management according to these requirements. I'd like there to be common patterns so there's at least a reasonable chance that you can plug my TTW UI for user management into your application without having to rewrite large parts of either. I'd also like this pattern to be there when I'm *writing* my larger application, so I say, 'okay, this is all for TTW user management' then, and then more easily extract it later. I don't want your TTW UI for user management. No offense to your TTW UI for user management, but the chances of it meeting my requirements for style, presentation, ease of use, look and feel are not high. If you have tools that make it pretty easy, I'd probably love to use them. But I'm going to be customizing it to my application anyways. Now - this is for applications whose user management may be turned over to the customer, or is expected to run within the user interface of my custom application. If I were using a more generic data management interface for administration (ZMI, etc), it might be a different story. 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. This may be in the direction of a solution. I haven't studied generations in detail, myself. Anyway, any such solution needs to be in the common codebase, otherwise we're going to end up with a lot of custom ones. Maybe. But I don't even know what the common codebase is going to be or wants to be these days. This is also a chance for someone to offer a here today alternative for others to install and use. [snip design ideas] * 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. I think ordering may become important eventually. I.e. I can only install my Foo thing into a site if Baz is already installed. I'd think I'd like to be able to express such ordering in some declarative way. Why not keep a lot of that declaration in Python? It has
Re: [Zope3-dev] Re: a new zcml directive?
Martijn Faassen wrote: Jean-Marc Orliaguet wrote: [snip] OK, basically you mean that the 'annotations' given in your original post should implement a 'setdefault' method? I don't see how that would help - you'd still end up writing a factory that uses the setdefault, right? I don't want to keep repeating factory code each time I want to do this, including factory code that calls IAnnotations(), uses setdefault() or anything else. I just want to say, I want to make an adapter that uses this standardized factory code. How the factory code does this is not very interesting, it's just that I don't want to keep writing it over and over. Regards, Martijn OK, you could pass the interface of the factory to the getter method and let it create the object based on this information. That wouldn't be exactly like setdefault(), but at least the factory code would be in the called method, not in the caller. If I remember correctly the pattern I'm using (which I still think is OK) is to register a factory as a global utility and look up the factory by its interface. so for instance to create a style or type IStyle, I register: cpsskins:setting name=style schema=.style.IStyle factory=.style.StyleFactory / with: def setting(_context, name=u'', schema=None, factory=None): ... provideUtility(factory, IFactory, name) then the annotation getter can contain a 'factory = getUtility(IFactory, name)' regards /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] Re: Coarse-grained reuse.
Hey Jeff, Jeff Shell wrote: On 3/16/06, Martijn Faassen [EMAIL PROTECTED] wrote: [snip] I'd like there to be common patterns so there's at least a reasonable chance that you can plug my TTW UI for user management into your application without having to rewrite large parts of either. I'd also like this pattern to be there when I'm *writing* my larger application, so I say, 'okay, this is all for TTW user management' then, and then more easily extract it later. I don't want your TTW UI for user management. No offense to your TTW UI for user management, but the chances of it meeting my requirements for style, presentation, ease of use, look and feel are not high. If you have tools that make it pretty easy, I'd probably love to use them. But I'm going to be customizing it to my application anyways. Now - this is for applications whose user management may be turned over to the customer, or is expected to run within the user interface of my custom application. If I were using a more generic data management interface for administration (ZMI, etc), it might be a different story. Frankly it sucks that you can't use my TTW UI for user management. Note that it's not just a UI. I'm talking about UI plus implementation, catalog install, groups support, hooks into authentication systems, etc. The point is that ideally I'd like to be able to reuse all that stuff as one bundle. Customization is fine, but I want customization, not: * everybody writing their own. * everybody having to copy large amounts of code or templates and modifying it in order to make it do what they like. Anyway, as a lower point of ambition, I want to at least be able to extract that code from the Document Library and use it in other applications I write. Whether you will find it useful is besides the point - it's not the be and end-all, but it's certainly better than having no way to do it at all. Note that this is not a hypothetical scenario. I *did* extract the code for user management from the Document Library so that it could be used in another Zope 3 project, not even one of my own. I was not happy with the amount of work it entailed, and now two codebases will use diverging copies of that code. I'm looking for patterns to prevent this from happening. [snip] This may be in the direction of a solution. I haven't studied generations in detail, myself. Anyway, any such solution needs to be in the common codebase, otherwise we're going to end up with a lot of custom ones. Maybe. But I don't even know what the common codebase is going to be or wants to be these days. This is also a chance for someone to offer a here today alternative for others to install and use. Whatever the common codebase is going to be, it better offer some patterns for how to install bundles of functionality. Perhaps this is a coding problem, perhaps it's a documentation problem, it's probably all combined, but it'd better be centrally communicated somehow. I do not want a situation where my app and your app just can't exchange code as they both built their own frameworks for installing extensions. Zope 3 is supposed to be on a mission to make this happen less. [snip] I think ordering may become important eventually. I.e. I can only install my Foo thing into a site if Baz is already installed. I'd think I'd like to be able to express such ordering in some declarative way. Why not keep a lot of that declaration in Python? It has amazing conditionals. Did I talk about having it be in Python or not? Let's not have that discussion here too... I don't care much where it is right now. I'm just saying that I want to be able to specify ordering in a *declarative* way. I don't want it to be in a bunch of if statements if you mean that, as that'd sounds rather brittle. [snip] I agree that just using ZCML obviously won't cut it. But perhaps some ZCML can at least help organizing the whole (pointing to the Python code to do the complicated stuff for each bit). That may be workable. But I'd also be happy with using just one directive (preferably adapter, subscriber, or utility) that would point to a single object that would do the complicated stuff for the whole thing. As long as it's declarative and clearly documented and everybody starts using it and it actually allows me to share my user management code, I'm fine with that too.:) 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] a plan for widgets?
Hi there, Let's come up with a plan for widgets. We have a very nice widget system in Zope 3, but it's not perfect. There are a bunch of things that could be improved: * the widgets are hanging out in dusty zope.app.form.browser. Perhaps it's time to move them into zope.widget? Not even in a browser subdirectory - after all, zope.widget is all about the browser! * there are various widget registrations missing. We should make sure to register them. * Jim tells me Don't look at SimpleInputWidget, it's too complicated. This sounds wrong and zope2-like; something called Simple that's too complicated. We need to figure out how to make that story less complicated. * sources and terms are nice, but we should at least provide some basic sources and register some basic terms for them; that bit is completely missing in Zope 3 right now. People should be able to at make a simple drop-down widget happen without having to figure out how to tie all these components together - they should just import and use the right source, perhaps import, use, and register the right term, and there they go. * there are widgets missing. Lots of people have useful widgets. Extensions with more widgets are very nice, but let's provide lots of useful widgets in zope.widget, too. Are people interested in developing a plan to tackle these issues? If some of us chip in we may get somewhere. 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] a plan for widgets?
On 3/16/06, Martijn Faassen [EMAIL PROTECTED] wrote: * Jim tells me Don't look at SimpleInputWidget, it's too complicated. This sounds wrong and zope2-like; something called Simple that's too complicated. We need to figure out how to make that story less complicated. Basically, it tries to be easily overrideable by create a whole host of methods that doesn't exist on other widgets, which you then can override. That basically makes no sense, if there is a function that should be easily overrideable, it should exist on a basic widget. Are people interested in developing a plan to tackle these issues? If some of us chip in we may get somewhere. Are widgets tied to schema fields now? I have the feeling they are, but maybe not. If they are, they should be more decoupled. -- 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] a plan for widgets?
Lennart Regebro wrote: On 3/16/06, Martijn Faassen [EMAIL PROTECTED] wrote: [snip] Are people interested in developing a plan to tackle these issues? If some of us chip in we may get somewhere. Are widgets tied to schema fields now? I have the feeling they are, but maybe not. If they are, they should be more decoupled. Just to interfaces of schema fields as views. The schema fields are in a hierarchy. I'm not sure how you would mean to decouple this. Anyway, my aim with this discussion is not to fundamentally overhaul the way widgets work, just to see what we can do relatively easily. 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] Re: a plan for widgets?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: snip * sources and terms are nice, but we should at least provide some basic sources and register some basic terms for them; that bit is completely missing in Zope 3 right now. People should be able to at make a simple drop-down widget happen without having to figure out how to tie all these components together - they should just import and use the right source, perhaps import, use, and register the right term, and there they go. zcml:ktupema_necro_halogo Hmm, another case where high-level ZCML support would be useful: defining simple terms for a vocabulary. Why should somebody who wants to tweak a vocabulary have to edit software? E.g.: vocabulary name=philosophers term id=platoPlato/term term id=aristotleAristotle/term term id=kantImmanuel Kant/term /vocabulary Of course, we could also keep the vocabularies in another data file, and merely have the high-level directive source it: zope:vocabulary name=philosophers file=philosophers.csv / /zcml:ktupema_necro_halogo 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 iD8DBQFEGZRq+gerLs4ltQ4RAqfjAKCVsLoGMDkvqbZVu7r+lPQzqvu3zwCeKYbS 7TZXr/3VwH64Z/w9jbH20sY= =ZUki -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] a plan for widgets?
On 3/16/06, Martijn Faassen [EMAIL PROTECTED] wrote: Just to interfaces of schema fields as views. The schema fields are in a hierarchy. I'm not sure how you would mean to decouple this. Anyway, my aim with this discussion is not to fundamentally overhaul the way widgets work, just to see what we can do relatively easily. Well, OK, one thing at a time. ;) -- 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] what is ZCML?
On 3/16/06, Martijn Faassen [EMAIL PROTECTED] wrote: Shane Hathaway wrote: [snip] 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 share these sentiments. Not that I have a particularly sick feeling (I've been immunized by too much exposure? :) but because I'm grasping for ways, patterns, to make my code look better, briefer, shorter, less repetition, more reuability. Reuse is overrated. :) Honestly, I think reuse best happens in Python. I've found it easy to wrap and roll things up into more common APIs for personal use. This has been one of the really positive things of Zope 3. But for that sort of roll up to happen, the environment needs to support common refactoring patterns (extract method/class/etc). I do not believe that ZCML supports that. I would feel more comfortable if one of the following things were to happen: 1. The group acknowledges that repetition in ZCML is bad. I definitely acknowledge his one. 2. Someone shows me how to avoid repetition in ZCML. Use less ZCML. Be creative. Have fun. This answer doesn't work for everybody, and isn't as easily applicable as I would like. 3. We decide that ZCML is a failed experiment. On the one hand, I'm not willing to do that. On the other hand, if ZCML is to be a simple registration language, I am starting to idly wonder why a bunch of CSV tables wouldn't do (and might not be clearer and simpler). Because editing CSV tables sucks an even bigger electrical outlet. (Honestly - I'm too stupid to understand Excel... But maybe I'm saying that after spending a week writing an CSV inventory importer. Ugh). If ZCML is to be a simple registration language, I'd also like there to be a 1 to 1 mapping of ZCML statement to Python code. Right now there is a mapping and while it may be reasonably straightforward, I personally am still lost in APIs (and it looks like Jeff Shell is too). This learning curve should be smaller. I agree. I think Jim said early on that ZCML should be theoretically replaceable. Looking at many of the directive implementations, I do not see this. If the Zope 3 CA vision that I had is to have a good chance of succeeding outside of this community, I'd hope that it doesn't ship with or require ZCML. Whatever we do, if ZCML is to be replaced we need to replace it with something. I think many of the notions of ZCML are dead on - this registration shouldn't be happening in normal Python code mixed with the rest but as a separate activity. It should allow overriding. It should be amenable to analysis. I'm mixed about whether this should happen in normal Python code. A few months ago I laid out a vision for how I think it would work. Basically, configuration would have to be a very locked-down module: it couldn't really be imported by regular code, wouldn't really execute when called from 'regular' code. It would, in short, try to somehow enforce the importing a package should NOT automatically register its components. 4. We decide that ZCML should gain more qualities of a high level language. I personally am quite interested in exploring this, but I'd like to see some examples of what this would actually look like, concretely. We have a high level language. It's Python. I think that people just have gotten bad at thinking in objects and usable APIs and have somehow developed a strange fear of the language. I don't get it. class ArticleEditForm(form.EditForm): form_fields = fields.FormFields(IArticle, ITaggable) form_fields['tags'].custom_widget = ... Wow. So much better than browser:editform. It's possible to design other parts of the system like this. I just know it is. like this? yes what is this? respects the Python developer. Now I know forms are a special case, as Tres or Shane or both brought up. I was just impressed by the amount of actually-helpful objects, APIs, and base classes in formlib. That one package has made me more productive and flexible than most of the rest of Zope 3's default elements (zope.interface/component/schema/app.container excepted). I think we can learn something from it. At least, I hope we can. Zope can, at the end of the day, only provide some good core tools. I think those tools, and the concepts behind them, should be simple. Then if someone wants to build the giga-framework on top of it, they can. But also, if I'm writing what should be a simple application like the PyWebOff example, I don't have to waste time on countless elements that don't apply. I don't have to waste time editing more XML than Python. Etc. Honestly: Rails is very appealing with its we use Ruby for everything message. But Ruby's syntax and use of blocks seems to make this more tenable than it is in Python. I'm not a big fan of their convention over configuration design, but it's winning me over slowly. The more I fight
Re: [Zope3-dev] a plan for widgets?
Hey Roger, Great to have you onboard on this! Roger Ineichen wrote: [snip] btw, didn't Gary Poster start a widget refactoring? Good question. I have no idea what the status of all that stuff is; whether anything got merged or not.. 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 plan for widgets?
On Thu, Mar 16, 2006 at 11:38:02AM -0500, Tres Seaver wrote: zcml:ktupema_necro_halogo eh? http://www.google.com/search?hl=enlr=q=ktupema+necro+halogobtnG=Search Your search - ktupema necro halogo - did not match any documents. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: a plan for widgets?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Winkler wrote: On Thu, Mar 16, 2006 at 11:38:02AM -0500, Tres Seaver wrote: zcml:ktupema_necro_halogo eh? http://www.google.com/search?hl=enlr=q=ktupema+necro+halogobtnG=Search Your search - ktupema necro halogo - did not match any documents. It is pseudo-Greek from the roots for beating dead horse. 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 iD8DBQFEGZ0k+gerLs4ltQ4RAtVZAKDacf6/4HCAOnZdLMWZavElzXtiKwCdEJqB xFnW72g4IFLA5AGrNZLSI8I= =UQeT -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] a plan for widgets?
On Thursday 16 March 2006 11:06, Martijn Faassen wrote: Are people interested in developing a plan to tackle these issues? If some of us chip in we may get somewhere. Gary has already begun the work of a widget replacement. Talk to him, he has some good ideas. 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
Re: [Zope3-dev] a plan for widgets?
Stephan Richter wrote: On Thursday 16 March 2006 11:06, Martijn Faassen wrote: Are people interested in developing a plan to tackle these issues? If some of us chip in we may get somewhere. Gary has already begun the work of a widget replacement. Talk to him, he has some good ideas. Okay, Gary, can we help? 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] a plan for widgets?
On Mar 16, 2006, at 11:42 AM, Martijn Faassen wrote: Hey Roger, Great to have you onboard on this! Roger Ineichen wrote: [snip] btw, didn't Gary Poster start a widget refactoring? Good question. I have no idea what the status of all that stuff is; whether anything got merged or not.. At ZC, several of us had enough experience with the zope widgets that we felt pretty confident that we wanted to start again, with a backwards compatibility story. We started, but ran out of steam, and didn't have a driving project for the changes, so we shelved it. We have an upcoming project that will want the changes. Our current plan is to develop what we need as zc.widget or something, and open- source it at the end when it's what we need, in the hopes that some will find it compelling enough to join in the maintenance and further development (btw, thanks, dobe, for the work on resourcelibrary!). No public timeframe. Doing it in the zc namespace is intended to make no assumptions about what happens with zope.app.form; zc.widget probably will have some backwards-compatibility with zope.app.form, but no dependencies. Gary ___ 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?
Jeff Shell wrote at 2006-3-15 14:26 -0700: ... 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? Maybe, because until that point it made life easier? I am very happy to use high level abstractions (provided they have well chosen names -- browser.addform seems quite good -- and a clear semantics) and start only to dig deeper when necessary. I treat a car as a black box with a well defined set of functions. Only when I reach the limits, I search deeper and may learn that there is a motor that can be tuned... ... 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). Things I agree with... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Reducing the Amount of ZCML Directives ready for review
Hi all, my work on http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives has been nearly completed on the philikon-reduce-zcml branch and is ready for review. What I didn't cover: * rdb:provideConnection wasn't removed. On a second thought, this directive also contains deployment information relevant to the system administrator (the DSN) that should not reside in Python code. * dav:provideInterface wasn't removed. Michael Kerrin's work on DAV is also calling for its removal so this is left for him to remove. * class/implements and class/factory weren't removed -- yet. I guess removing these might be a bit controversial. I'd therefore like to take this opportunity to bring this topic up again and to give everyone a chance to look at the proposal once again, before I start spending lots of time on the implementation. If no one objects to the branch as it is, I will merge it on the weekend. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.configuration
Lets step back and look at why we created ZCML. A primary goal of the component architecture was to make it easier to reuse packages. A major problem with Zope 2 products is that they are hard to customize. The CMF made this a bit better with skins. You could override selected scripts or templates provided by a product by providing overriding versions in your own products or by customizing through the web. You don't have to modify the original product. With the component architecture, you can override at the level of components. As with the CMF, we need to be able to override components without modifying the original package. The zope.configuration package provides a framework for defining and overriding configurations. It *also* supports an XML syntax. It supports other syntaxes too. (This support may have atrophied somewhat from lack of use. :) In fact, the original syntax for zope.configuration was a simple text-based syntax. The configuration framework is based on computing sequences of actions. When a ZCML file is processed, the individual handlers compute lists of actions. These actions are accumulated as different files are processed. An action includes: - a discriminator used to detect conflicting actions. Two or more actions conflict of they have the same discriminator. An action may have None as it's discriminator, in which case, it cannot conflict with another action. - callable, positional, and keyword arguments, - include path used to resolve conflicts. If there is an action in a set of conflicting actions whose include path is a proper prefix of the include paths of all of the other conflicting actions, then the conflict is resolved by keeping this action and discarding the other actions. This is why a file that includes another file can have a directive that overrides directives in the included file. - info that documents the action. - order (lame) that can be used to affect the order in which an action executes. A very high number can be used to make an action execute relatively last. Configuration processing proceeds in 3 steps: 1. Actions are generated, typically by processing ZCML files. (We'll ignore meta-configuration in this discussion. :) 2. Actions generated in step 1 are analyzed for conflicts. If any conflicts can't be resolved, they are reported as errors. The action info is used in the generation of these errors. 3. Actions are executed by calling their callables with their positional and keyword arguments. The resolution of conflicts in stage 2 is critical for achieving the goal of the configuration framework, which is overriding. The way actions are generated is not critical. (Note that a flaw in this model is that we have no good way to undo actions. We don't need this for normal execution, but it would be very helpful for testing.) Actions need not be generated by executing ZCML. They can be generated by processing configuration files in other formats. They could even be generated by Python code. I'm told that that's what Launchpad does. I'd have no problem with generating actions in Python. It would allow greater control and would probably make action generation much faster. If we did this, We'd probably want to improve the action-generation API. We'd also need to think about how action info should be generated, especially wrt error reporting. Perhaps we should support both ZCML and python action generation. 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 plan for widgets?
On 3/16/06, Tres Seaver [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: snip * sources and terms are nice, but we should at least provide some basic sources and register some basic terms for them; that bit is completely missing in Zope 3 right now. People should be able to at make a simple drop-down widget happen without having to figure out how to tie all these components together - they should just import and use the right source, perhaps import, use, and register the right term, and there they go. Um. Straight up sources are pretty easy, especially when you use terms directly. We have a few Choice (and our own 'RelaxedChoice') fields in one application that get their values, at present, from tuples in a ``values.py`` file. ``values=values.area_codes``. Works fine for straight and simple sources. The problem I have with vocabularies is, ahem, the vocabulary. they should just import and use the right source, perhaps import, use, and register the right term, and there they go... what? As I mention below, I've ultimately started to find Vocabularies very useful. But I also found them incredibly daunting with a surprisingly high entry barrier. Terms, Tokens, Titles, deferred vocabulary loading and binding, direct vocabulary-field binding, the vocabulary registry (versus the Utility registry), the different vocabulary registry set up in zope.app, ... It's been hard to control and understand. And especially (strangely) hard to learn by interaction in the Python interpreter. zcml:ktupema_necro_halogo Hmm, another case where high-level ZCML support would be useful: defining simple terms for a vocabulary. Why should somebody who wants to tweak a vocabulary have to edit software? E.g.: vocabulary name=philosophers term id=platoPlato/term term id=aristotleAristotle/term term id=kantImmanuel Kant/term /vocabulary Of course, we could also keep the vocabularies in another data file, and merely have the high-level directive source it: zope:vocabulary name=philosophers file=philosophers.csv / /zcml:ktupema_necro_halogo If - and only if - and really really really really really only if - you mean to do this, fix the HELL up the vocabulary registration stuff. That's where most of my time got lost when I had that debugging session the other week that pissed me off to no end about ZCML. I have no idea how I fixed my situation either. By the way, isn't it pretty easy to provide straight up values anyways for those quick drop-down situations? trip_type = zope.schema.Choice( title=_(uTrip Type), description=_(uTrip Type), default=uBusiness, required=True, values=(uBusiness, uPersonal), ) replacementOptions = SimpleVocabulary(( SimpleTerm(value='none', title='No - keep all current articles'), SimpleTerm(value='matching', title='Only replace matching IDs'), SimpleTerm(value='all', title='Yes - replace all existing articles'), )) class ImportSchema(Interface): importfile = zope.schema.Bytes( title=uImport Zip File, description=uZipe file of items to import., required=True, ) replace = zope.schema.Choice( title=uReplace existing articles?, vocabulary=replacementOptions, default='none', ) class ImportArticlesForm(form.Form): ... @form.action(uImport Articles, failure='handleFailure') def importArticles(self, action, data): replace = data['replace'] zipped = self.openZip(data['importfile']) if replace == 'all': self.clearExistingArticles() ... Maybe someday I'll force us at Bottlerocket to make the time for me to at least put up a version of my knowledge base app so I can publish recipes I put up on the mailing list. I think that a lot of the easy / relatively easy aspects get obscured or lost. A recipe or tip for how do I make a simple drop down? would be nice. ___ 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 plan for widgets?
On Thu, Mar 16, 2006 at 08:06:11PM -0700, Jeff Shell wrote: | By the way, isn't it pretty easy to provide straight up values anyways | for those quick drop-down situations? | | trip_type = zope.schema.Choice( | title=_(uTrip Type), | description=_(uTrip Type), | default=uBusiness, | required=True, | values=(uBusiness, uPersonal), | ) | | replacementOptions = SimpleVocabulary(( | SimpleTerm(value='none', title='No - keep all current articles'), | SimpleTerm(value='matching', title='Only replace matching IDs'), | SimpleTerm(value='all', title='Yes - replace all existing articles'), | )) | class ImportSchema(Interface): | importfile = zope.schema.Bytes( | title=uImport Zip File, | description=uZipe file of items to import., | required=True, | ) | | replace = zope.schema.Choice( | title=uReplace existing articles?, | vocabulary=replacementOptions, | default='none', | ) Yum Yum. That reminds me of Archetypes-Hum. -- Sidnei da Silva Enfold Systems, Inc. http://enfoldsystems.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
