[Zope3-dev] Re: [Zope-dev] Pluggins vs Application Definition
[aside... hmmm, crossposting, maybe time to merge zope-dev and zope3-dev? most stuff seems to be relevent to both nowadays] Jim Fulton wrote: In Zope 3, we went with a more explicit installation mechanism, in which people had to explicitly cause a package's ZCML files to be loaded for it to be used. We added a mechanism to make this easier, by simply dropping a file into a special directory, package-includes, so an installer wouldn't have to fool with pointy brackets. Personally, I hate package-includes. It creates a load of mess in a folder that is likely to need to have new tools written to look after it in the future :-/ I'd really like to just see lines getting includes in site.zcml. There is precedent for this, very good precedent in fact. Think of httpd.conf, and the module include lines at the top. I'm all for supporting having squillions of files all over the place, but I'd really like to see the default be one file, as with Apache. Also, I wish there was some way to have a .zcml that is in the _software_ home, not the package home, that inlcuded all the standard bits so that when I upgrade my zope version, I don't have to worry about juggling all those files and wondering which ones are out of date and which ones have new versions... - If the application is extensible, then application users will want to be able to extend the application by adding pluggins. This also applies particularly to framework applications like CMF... If application users are not technically sophisticated, or, more importantly, not technically interested, they peobably would prefer to just drop something into a special directory and be done with it. Yup, /products, /plugins, etc, everything from Photoshop to Zope 2 has this concept ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Pluggins vs Application Definition
Stephan Richter wrote: This is interesting. I agree with Philipp though that a simple install tool would be better than one magic location. Indeed, but don't eggs already provide tools for this? I think the ZCML slugs are very cool I think they suck, sorry... it's one of the first things I hit with Zope 3 over Christmas :-( and if we have a tool (as make does now) Please god, not make... that does this one step, then we effectively have drop-in packages. No, drop in packages means you either use a package-manner like interface, like aptitude, a binary installer, or actually dropping a single file into a directory. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] My proposals on simplifying ZCML
Dear all, thanks to everyone who commented my two proposals on simplifying ZCML. Here are some updates: Reducing the amount of ZCML directives -- I've updated this proposal slightly. It now mentions the important characteristics of ZCML directives and lists an additional risk pointed out by Martijn. It also proposes to simplify the content/class directive, something which I had forgotten to mention before. Still look for comments at http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives ... One namespace for ZCML -- There have a lot of negative comments on this (even though my initial idea got several +1 on this list). I think the discussion was still helpful. It definitely proved my point that we don't really have good guidelines for managing ZCML namespaces. A lot of people also agreed with me that we have too many namespaces. My proposal of removing all namespaces was a bit too drastic, I guess. I will create a new proposal that will only focus on: * coming up with guidelines for creating and managing ZCML namespaces * consolidating some unnecessary namespaces that we have today into one * making ZCML a better citizen with other XML dialects I'll welcome any suggestions if some of you have any... Stay tuned :). Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] Pluggins vs Application Definition
Chris Withers wrote: [aside... hmmm, crossposting, maybe time to merge zope-dev and zope3-dev? most stuff seems to be relevent to both nowadays] +10 You know, I once had a proposal. Uh, never mind :) In Zope 3, we went with a more explicit installation mechanism, in which people had to explicitly cause a package's ZCML files to be loaded for it to be used. We added a mechanism to make this easier, by simply dropping a file into a special directory, package-includes, so an installer wouldn't have to fool with pointy brackets. Personally, I hate package-includes. It creates a load of mess in a folder that is likely to need to have new tools written to look after it in the future :-/ I'd really like to just see lines getting includes in site.zcml. We had that once. We got rid of it because it made deployment harder. With slugs you can just drop in an extra file without having to change one. That makes automated installation easy. There is precedent for this, very good precedent in fact. Think of httpd.conf, and the module include lines at the top. I'm all for supporting having squillions of files all over the place, but I'd really like to see the default be one file, as with Apache. Heh, that's actually a funny example because Debian has actually been using modular config files for quite some time now (not only for Apache). Especially module includes, module configurations and virtual sites all rest in individual config files. Small tools (a2enmod, a2ensite) help manage the files, though manual management isn't too hard either. So, seems like not only are we the first ones to come up with a setup like that, it's also used by a large Also, I wish there was some way to have a .zcml that is in the _software_ home, not the package home, that inlcuded all the standard bits so that when I upgrade my zope version, I don't have to worry about juggling all those files and wondering which ones are out of date and which ones have new versions... You should know which ones you want in your instance anyways. I rather have a very, very slim standard set of packages and make everything else optional than provide everything else by default. If the software home ZCML file (which essentially is zope.app/configure.zcml) includes too much, it's a pain to disable things you don't like. It's trivial with package-includes. If application users are not technically sophisticated, or, more importantly, not technically interested, they peobably would prefer to just drop something into a special directory and be done with it. Yup, /products, /plugins, etc, everything from Photoshop to Zope 2 has this concept ;-) It's been giving us a lot of pain in Zope 2. I don't think anyone seriously wants to go back. We *can* have a standardized location (by convention), e.g. $INSTANCE_HOME/lib/python, but let's not make it a mandatory one. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] Pluggins vs Application Definition
On Wednesday 15 February 2006 07:20, Philipp von Weitershausen wrote: Chris Withers wrote: [aside... hmmm, crossposting, maybe time to merge zope-dev and zope3-dev? most stuff seems to be relevent to both nowadays] +10 Okay, I hope this would be ignored, but -1. I can still ignore many E-mails on Zope-Dev. 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] Re: One namespace for ZCML
Roger Ineichen wrote: I'm interessted in a menu / menu item refactoring. This means, we could get rid of the implicit magicly registred menus in other directives which ends in unaccessible menu items and will offer a better accessible API. I will write a proposal later, but perhaps I have to prototype first since this part is very complex and used almost in every browser directive. Note that my other proposal, ReducingTheAmountOfZCMLDirectives, mentions something like this in the end (it's not really part of the actual proposal anymore, just some random thoughts): Many directives of the browser namespace support the registration of menu items in addition to registering the component in question. Though this can be considered useful because it might save some typing, keeping directives as simple as possible (on/off switches!) might be weighed higher. People are certainly intimidated by the length of some of the browser directives (such as browser:editform); by taking the menu functionality out, we could reduce many directives by two lines making them easier to understand by themselves (of course, we'll have to add another menu directive, but it'll only be 3 or so lines). If you got any further comments on this, I'd be happy to hear them. It doesn't *have* to be a proposal, but it would sure be nice :). Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Last chance to comment on Simplify skinning
Dear Tonico, thanks for your input. In CMF things are very easy to understand, because a layer is simply a folder. I can explain that in five minutes to a template programmer. Why does the template programmer need to know about layers? Maybe this sounds a bit NAIVE, but would it be possible to make it like in CMF? The CMF approach is very limiting. The fact that a layer equals a physical location (a folder) led to every CMF-based product coming up with its own layer -- because there is no way to put stuff into existing layers, not even the default layer. Layers as they are in Zope 3 have stopped this senseless layer proliferation. I find Zope 3's approach much simpler and much easier to explain than the CMF's approach. In Zope 3 (especially with my proposed changes in place), a layer is simply a label (read: marker interface) on the request. When we now look up pages and resources (e.g. images), we take the request into account and therefore inevitably that label. We will only find pages and resources associated (read: registered) for this label. Good news is that any page or resource can be associated for this label, we just have to remember to do that in their ZCML directive. See, now I even explained this to a template programmer, though I don't think he'd care. Use case: Integrate an existing application into my Web site, e.g. a forum. 1. Create a folder for the customized forum skin $ mkdir forum-skin 2. Register this folder blah:skin-folder path=forum-skin ... / 3. Customize everything from original forum skin $ cd forum-skin $ cp $ORIGINAL_FORUM_SKIN/*.pt . $ vi * This is oversimplified, I know :) Yes. It's also limiting. Another note: when I see this I feel a cold shudder: browser:resource name=zope3logo.gif file=shanghailogo.gif type=.interfaces.ShanghaiSkin / Quite a lot of typing for one GIF!? Registering resources explicitly gives us the ability to easily override resources. That'll allow us to change logos, icons, etc. with just one ZCML directive. In fact, the ability to override is *the* foremost use case for registering stuff explicitly at all. If you want to save typing, you can have resource directories where you dump anything you want to be available as a resource. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
Jeff Shell wrote: I still HATE magical ZCML. But I still think ZCML is a good thing and should be modularized. Simplified - yes. Modular (namespaces) - yes. That seems to be the core message of most of the feedback I got. I'll be happy to hear more detailed suggestions on what should be simplified and/or modularized. Of course, I also have a few of my own, some of them are already listed at the bottom of the other proposal... Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Reducing the amount of ZCML directives
Lennart Regebro wrote: I think I agree. This to me makes sense. If it were nameless (are there nameless utilities) you could then get off with just utility component=.alias.sydneyFactory / which is then the on/off switch we mentioned earlier. And an adapter should be registered the same way adapter component=.alias.FidgetAdapter / and what it adapts between should be a part of the python-code with an adapts(ISomething) declaration, just like implements(ISomethingelse), which I think you suggested in your ZCML does doo much blog, right? Among other things, yes. The idea isn't mine though, it was Jim's and is already in-place as of Zope 3.2/2.9. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
On Wednesday 15 February 2006 07:59, Philipp von Weitershausen wrote: I realize that and I think at least the concern was valid. As for the solution, I rather prefer the convenience (which reads for me as automation when it get rids of dead chicken direcives) to be in Python. But I think this is exactely the problem. Convenience is often geared towards non-technical people, like designers and integrators. For them to touch or write Python code is horrifying. One of the goals of ZCML was to address this audience and day: Look add, edit or change this and that directive and you are good to go. It was also one of the reasons XML was chosen. 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] RFC: Reducing the amount of ZCML directives
On 2/15/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Among other things, yes. The idea isn't mine though, it was Jim's and is already in-place as of Zope 3.2/2.9. Oh, I missed that, I thought it was planned for 3.3. :-) -- 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] One namespace for ZCML
Philipp von Weitershausen wrote: Martijn Faassen wrote: [snip] Moreover, sometimes a package introduces new ways to configure components. Five does so, for instance, and Silva will too eventually. I would really like to hear what kind of directives you imagine for Silva here (and what you mean by new ways to configure components). The following are candidates, though note I haven't thought this through deeply for any of them: * a way to register a Silva content object. * a way to register a content object version. * a way to register a Silva metadata set. * registering directory views (could go into CMF, though Silva is not using it directly now) * a way to register an XSLT renderer. * registering XML importers and exporters. * registering a silva service into the Silva root * configuring which objects can be addable. * setting up zope 2 permission/role mapping in Silva root. * setting up the zope 2 catalog indexes. I think some, or even all, of these can probably turn *eventually* into Zope 3-style approaches directly - probably services will become some sort of local utilities, and directory views will become Zope 3 view, XSLT another, and the importers/exporters will become some sort of adapters, addables menus. The emphasis is on eventually, as I certainly expect it to be useful in a transition phase to clean out Silva's current grotty install.py and replace it with ZCML that doesn't require significant refactorings of Silva yet. Replacing this stuff with native Zope 3 components is generally a major task. I expect a very similar story applies to CMF, and again to CMF-based systems like Plone. Sometimes a new, short directive is a lot easier to remember than to remember long.dotted.names.pointing.to.places and 3 directives. Having to remember (or worse, look up) long dotted names is extremely common in ZCML and I consider it at least as big a problem as having to learn directives. I agree. Many of these long dotted names belong into Python, though. Let's use abstraction and naming things where it makes sense. Heh, perhaps we need to go the other way and add a namespace directive for long dotted names instead. :) -1. I put in a smiley, but I'm serious about the underlying problem of exposing a lot of long dotted names into Python modules into ZCML. I wonder whether we can do things to make this look simpler. If the dotted names were not hiding in attributes but in element content, we could come up with some kind of XML vocabulary for them, even. :) That said, there might still be a small percentage of cases where custom directives are a valid tool. I can accept their being on the same namespace as others. In fact, I would like it to be that way, reducing the amount of dead chickens (namespace declarations). Namespace declarations are not dead chickens. They're things that the XML language requires. Indentation and colons are not dead chickens in Python either. *particular* namespace declarations may be unnecessary - but not dead chickens, just perhaps the wrong solution. Yeah, sorry, bad wording. I just think having to declare 3 to 5 different namespaces on the top of the file of which some have no apparent meaning or distinction seems like clutter to me. Some indeed have no apparent meaning and distinction; I think zcml:condition could be safely folded into Zope's namespace. When I see apidoc or wfmc I can identify what is involved, though - possibly they can still be eliminated but they definitely have meaning to me. In the documentlibrary, so far we've only used two namespaces, zope and browser. In schooltool, more namespace happen: apidoc, wfmc, i18n and zcml. I think eliminating the 'zcml' namespace would get us down to 2 or less declarations for most .zcml files. Note that I absolutely see the necessity for namespace declarations. For example, I would like to see ZPT require the declaration of TAL, METAL and I18N namespaces. Note that there the entire namespace story is different. There they are used for what I think namespaces are intended, separating several XML models (e.g. the HTML model from the additional TAL/METAL/I18N model). I think Zope 3 extensions extend the Zope 3 XML model. They're less different than combining XHTML with TAL, but I still see a core vocabulary with potentially arbitrary extensions. 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: Last chance to comment on Simplify skinning
Philipp von Weitershausen wrote: In CMF things are very easy to understand, because a layer is simply a folder. I can explain that in five minutes to a template programmer. Why does the template programmer need to know about layers? Because in CMF, if you want to customize or create a skin, you need to know about the so called layers. Maybe this sounds a bit NAIVE, but would it be possible to make it like in CMF? The CMF approach is very limiting. The fact that a layer equals a physical location (a folder) led to every CMF-based product coming up with its own layer -- because there is no way to put stuff into existing layers, not even the default layer. Layers as they are in Zope 3 have stopped this senseless layer proliferation. I find Zope 3's approach much simpler and much easier to explain than the CMF's approach. In Zope 3 (especially with my proposed changes in place), a layer is simply a label (read: marker interface) on the request. When we now look up pages and resources (e.g. images), we take the request into account and therefore inevitably that label. We will only find pages and resources associated (read: registered) for this label. Good news is that any page or resource can be associated for this label, we just have to remember to do that in their ZCML directive. See, now I even explained this to a template programmer, though I don't think he'd care. Maybe I mean something different. I just want a folder in which I can drop all the files I want to customize (I love to customize), without registering something. Is this a layer? You're right, I don't care :) Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Last chance to comment on Simplify skinning
Tonico Strasser wrote: In CMF things are very easy to understand, because a layer is simply a folder. I can explain that in five minutes to a template programmer. Why does the template programmer need to know about layers? Because in CMF, if you want to customize or create a skin, you need to know about the so called layers. But we aren't in the CMF :). Seriously, you are right about the fact that you need to know about layers when you want to work with skins. Let's just be clear on the actors' names: template programmer isn't necessarily the same as a skin customizer. A template author just writes a page template and isn't necessarily concerned how and where it is going to be registered. Most of the time, it is fine to register browser pages (incl. template-based ones) for the default layer. That is a huge difference to the CMF where everything lives in a very specific layer (which I find annoying and complicated) and that layer has to be registered in a skin (which most CMF product's Install.py will automatically do...). Now, the skin customizer might write some templates to actually perform some customization first, but his job description really is about setting up the layer(s) and registering one of them as a skin. For that you need to know about layers, yes. But not when you only want to author a template. Maybe this sounds a bit NAIVE, but would it be possible to make it like in CMF? The CMF approach is very limiting. The fact that a layer equals a physical location (a folder) led to every CMF-based product coming up with its own layer -- because there is no way to put stuff into existing layers, not even the default layer. Layers as they are in Zope 3 have stopped this senseless layer proliferation. I find Zope 3's approach much simpler and much easier to explain than the CMF's approach. In Zope 3 (especially with my proposed changes in place), a layer is simply a label (read: marker interface) on the request. When we now look up pages and resources (e.g. images), we take the request into account and therefore inevitably that label. We will only find pages and resources associated (read: registered) for this label. Good news is that any page or resource can be associated for this label, we just have to remember to do that in their ZCML directive. See, now I even explained this to a template programmer, though I don't think he'd care. Maybe I mean something different. I just want a folder in which I can drop all the files I want to customize (I love to customize), without registering something. That's not how it works in Zope 3, at least not right now and not by default. My proposal doesn't isn't addressing this. Shane has expressed an interesting idea that goes into the I just drop my stuff in here direction, but I'm frankly missing some important points in this idea yet. It might be interesting to develop it further, though. For now, however, we have to explicitly register everything. I consider that a good thing. Is this a layer? A layer is a marker interface on the request (Zope 3 definition). You're right, I don't care :) I think you don't care for the wrong reasons. You want your CMF experience duplicated. Perhaps you're not as bothered as I was with the CMF's limitations, but it sured annoyed me as hell having to create a new layer for every product I wrote for CMF. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
Martijn Faassen wrote: I would really like to hear what kind of directives you imagine for Silva here (and what you mean by new ways to configure components). The following are candidates, though note I haven't thought this through deeply for any of them: * a way to register a Silva content object. * a way to register a content object version. * a way to register a Silva metadata set. * registering directory views (could go into CMF, though Silva is not using it directly now) ... * registering a silva service into the Silva root * configuring which objects can be addable. * setting up zope 2 permission/role mapping in Silva root. * setting up the zope 2 catalog indexes. I guess most of these fall under the registering something that isn't a utility or adapter category which is fine. Though I wouldn't be surprised some of those registrations could be boiled down to simpler, Zope-3-style things like menu items or utilities. Oh wait, you mention that yourself :). * a way to register an XSLT renderer. * registering XML importers and exporters. These two immediately triggered adapter in my mind :). I think some, or even all, of these can probably turn *eventually* into Zope 3-style approaches directly - probably services will become some sort of local utilities, and directory views will become Zope 3 view, XSLT another, and the importers/exporters will become some sort of adapters, addables menus. The emphasis is on eventually, as I certainly expect it to be useful in a transition phase to clean out Silva's current grotty install.py and replace it with ZCML that doesn't require significant refactorings of Silva yet. Replacing this stuff with native Zope 3 components is generally a major task. I agree on the eventuality. It's important, though, that we do try to find a good match between the Zope 3 ways of doing things and the historical baggage. In Zope 3 we have developed a nice way of looking at things and fit them into very simple concepts. It should be preserved. Btw, I find it a bit scary that you're trying to replace an install method with a lot of ZCML directives. I'm not sure I would welcome a procedure expressed through configuration. It seems like some of these problems are better tucked away using a deployment framework like GenericSetup. But then again, I'm not really familiar with Silva and that install.py thing. Sometimes a new, short directive is a lot easier to remember than to remember long.dotted.names.pointing.to.places and 3 directives. Having to remember (or worse, look up) long dotted names is extremely common in ZCML and I consider it at least as big a problem as having to learn directives. I agree. Many of these long dotted names belong into Python, though. Let's use abstraction and naming things where it makes sense. Heh, perhaps we need to go the other way and add a namespace directive for long dotted names instead. :) -1. I put in a smiley, but I'm serious about the underlying problem of exposing a lot of long dotted names into Python modules into ZCML. No worries, I got the tone of the message. However, to every satire there's a true core message, as you're pointing out yourself. I too am concerned, but I also think that because dotted names actually have a meaning, they might be handier in the end than cryptic short forms. And then there's also the point of intrinsic information of a component that we're currently putting into ZCML but are starting to put into Python. I has already reduced the amount of dotted names necessary. I wonder whether we can do things to make this look simpler. If the dotted names were not hiding in attributes but in element content, we could come up with some kind of XML vocabulary for them, even. :) At least it would give you the possibility to define and use XML entities for them :). Seriously, though, I wouldn't be sure of my vote for a system like that. As said, dotted names have a meaningful background (Python import paths). Abbreviations most likely don't. I rather build something that makes sense than one that relies on too many naming conventions... That said, there might still be a small percentage of cases where custom directives are a valid tool. I can accept their being on the same namespace as others. In fact, I would like it to be that way, reducing the amount of dead chickens (namespace declarations). Namespace declarations are not dead chickens. They're things that the XML language requires. Indentation and colons are not dead chickens in Python either. *particular* namespace declarations may be unnecessary - but not dead chickens, just perhaps the wrong solution. Yeah, sorry, bad wording. I just think having to declare 3 to 5 different namespaces on the top of the file of which some have no apparent meaning or distinction seems like clutter to me. Some indeed have no apparent meaning and distinction; I think zcml:condition could
[Zope3-dev] Re: One namespace for ZCML
Stephan Richter wrote: I realize that and I think at least the concern was valid. As for the solution, I rather prefer the convenience (which reads for me as automation when it get rids of dead chicken direcives) to be in Python. But I think this is exactely the problem. Convenience is often geared towards non-technical people, like designers and integrators. For them to touch or write Python code is horrifying. I don't think designers will have to touch Python. I don't even think they will often touch ZCML. The designers I hired never had to... One of the goals of ZCML was to address this audience and day: Look add, edit or change this and that directive and you are good to go. It was also one of the reasons XML was chosen. I think ZCML is addressing people who build packages, people who make applications out of these packages and people who deploy those applications. I think in all three cases we can assume enough experience with Zope and Python to expect them to enter, say, a dotted name. And, of course, these people typically overlap. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: tal:define=... considered harmful?
Balazs Ree wrote: On Mon, 13 Feb 2006 18:59:32 +0100 Martijn Faassen wrote: Jean-Marc Orliaguet wrote: I've being working on integrating Balazs Ree's CTAL interpreter recently (added tests, fixes, etc.). CTAL is the equivalent of TAL but for javascript. I just googled around for this, and couldn't find it, but I'm intrigued. Any link? I made it some time ago just as an experiment, I was interested in having the equivalent of TAL on the client side. The implementation is far from complete but it's actually usable. If you are interested, best to check it out from the link Jean-Marc gave in the other mail (and I indeed might put it up somewhere in svn on its own). A separate svn project would be nice. I'm sure z3lab is open; it's also welcome under the z3 base on codespeak. I think the main advantage is that if someone already knows TAL can generate html from a template and raw data on the client side (which is one of the tipical AJAX usage patterns) without the need to learn another method or write dom manipulation in javascript. Right, that was my motivation too - I googled around for javascript-based templating languages but realized there wasn't really anything. Of course XSLT can be used this way too, but TAL is kinda neat too. Still, I couldn't think of much practical use for this. Perhaps in this AJAXy world this has changed. Are you interested in recovering some of there Zope TAL based regex stuff from Sapling? I'd be happy to merge it in. ctal doesn't appear to have this yet. 'ctal' is a somewhat confusing name by the way, you'd think it was TAL implemented in C, another interesting project I've dabbled with on and off in the past. We had an CVS to SVN conversion earlier this week, so sapling's source code is now here: https://infrae.com/viewvc/sapling/trunk/ (check it out with: svn co https://infrae.com/svn/sapling/trunk sapling) It has tests and everything. :) 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: Last chance to comment on Simplify skinning
Tonico Strasser wrote: Philipp von Weitershausen wrote: [snip] See, now I even explained this to a template programmer, though I don't think he'd care. Maybe I mean something different. I just want a folder in which I can drop all the files I want to customize (I love to customize), without registering something. Is this a layer? You're right, I don't care :) I know this is on a side track from the simplify skinning discussion, but: I think it'd be nice to have something that allowed you to register at least resources in a directory that still keeps intact the overriding capabilities that you'd have if you were to register a single resource. The current directive to register a directory of resources makes it easy to register a whole bunch of them in one go, but, unless I'm mistaken, makes it hard to override just *one* later (in another skin or override), as in fact the directory it registered directly. 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] One namespace for ZCML
Philipp von Weitershausen wrote: Martijn Faassen wrote: [snip] * a way to register an XSLT renderer. * registering XML importers and exporters. These two immediately triggered adapter in my mind :). XSLT renderer may be a view, that's how we use them now. I think it's a candidate for a fairly easy transition to Zope 3 style concepts, in fact. There are subtleties with XML importers that don't really map to adapters directly, at least not in a simple way - you want to register different importers for certain XML tags. [snip] It's important, though, that we do try to find a good match between the Zope 3 ways of doing things and the historical baggage. In Zope 3 we have developed a nice way of looking at things and fit them into very simple concepts. It should be preserved. Sure, but I want my silva namespace so I don't pollute the Zope 3 space. :) Same reason I'm happy with the five namespace. Btw, I find it a bit scary that you're trying to replace an install method with a lot of ZCML directives. I'm not sure I would welcome a procedure expressed through configuration. It seems like some of these problems are better tucked away using a deployment framework like GenericSetup. But then again, I'm not really familiar with Silva and that install.py thing. Silva's 'install.py' does a lot of stuff that really should be declaration, not procedure. Registering metadata sets for content types, registering views, etc, etc. Then extensions to Silva also do the same thing. GenericSetup would make sense for some of it, but I suspect fairly little, except of course that right now lots of Silva's configuration, often unnecessarily, ends up in the ZODB. [snip] I put in a smiley, but I'm serious about the underlying problem of exposing a lot of long dotted names into Python modules into ZCML. No worries, I got the tone of the message. However, to every satire there's a true core message, as you're pointing out yourself. I too am concerned, but I also think that because dotted names actually have a meaning, they might be handier in the end than cryptic short forms. And then there's also the point of intrinsic information of a component that we're currently putting into ZCML but are starting to put into Python. I has already reduced the amount of dotted names necessary. Yes, I saw that point of yours in another thread replying to me there, and I think that's a very good point. Anyway, in my attitude to ZCML I'm for piecemeal evolution right now - I don't think ruthless refactoring is really necessary, but we can get quite ruthless on certain directives or attributes of certain directives. I wonder whether we can do things to make this look simpler. If the dotted names were not hiding in attributes but in element content, we could come up with some kind of XML vocabulary for them, even. :) At least it would give you the possibility to define and use XML entities for them :). Seriously, though, I wouldn't be sure of my vote for a system like that. As said, dotted names have a meaningful background (Python import paths). Abbreviations most likely don't. I rather build something that makes sense than one that relies on too many naming conventions... Agreed; this needs to be thought through carefully. We don't want to replace dotted names with a lot of shorter stuff you need to memorize anyway, either. It needs to be somehow predictable, and perhaps dotted names are the best we can do, if we can at least get rid of some of them and move it into Python. It's just an interesting area to think about. I just think having to declare 3 to 5 different namespaces on the top of the file of which some have no apparent meaning or distinction seems like clutter to me. Some indeed have no apparent meaning and distinction; I think zcml:condition could be safely folded into Zope's namespace. When I see apidoc or wfmc I can identify what is involved, though - possibly they can still be eliminated but they definitely have meaning to me. In the documentlibrary, so far we've only used two namespaces, zope and browser. In schooltool, more namespace happen: apidoc, wfmc, i18n and zcml. I think eliminating the 'zcml' namespace would get us down to 2 or less declarations for most .zcml files. I think the 'zcml' namespace should be separate from the 'zope' one because 'zcml' is meta-ish whereas 'zope' is about actual and factual directives. I would rather see 'meta' directives folded into 'zcml' (like I propose in the proposal). zope:include and friends are meta-ish too though. Moving those into a separate namespace would suddenly grow the amount of namespaces necessary. Perhaps folding the meta namespace (+ zcml) into zope is actually something we can explore. The meta namespace should be a fairly solid XML vocabulary after all. Note that I absolutely see the necessity for namespace declarations. For example, I would like to see ZPT require the declaration of TAL, METAL and I18N
Re: [Zope3-dev] Re: [Zope-dev] Pluggins vs Application Definition
Chris Withers wrote: maybe time to merge zope-dev and zope3-dev? -1 They're still different enough that most traffic on one is not interesting to the majority of subscribers to the other. -- Benji York Senior Software Engineer Zope Corporation ___ 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: tal:define=... considered harmful?
Martijn Faassen wrote: Right, that was my motivation too - I googled around for javascript-based templating languages but realized there wasn't really anything. Of course XSLT can be used this way too, but TAL is kinda neat too. Still, I couldn't think of much practical use for this. Perhaps in this AJAXy world this has changed. Personally I'm very excited about ctal (and like the name too). Getting data objects from the server and feeding them to templates on the client seems like a nice way to do AJAXy things. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Re: tal:define=... considered harmful?
On Wed, 15 Feb 2006 16:41:36 +0100 Martijn Faassen wrote: A separate svn project would be nice. I'm sure z3lab is open; it's also welcome under the z3 base on codespeak. I will then check it in to one of those; seriously, I can't decide which location would be more proper as a home. The z3base seems more generic to me, however the other ajax stuff is already in z3lab. (except AZAX, which has the kukit part stored on codespeak.) I am facing the same decision at where to bring in the jsonserver (a.k.a. json-rpc) product which would be a complete zope2-zope3 product merge. Are you interested in recovering some of there Zope TAL based regex stuff from Sapling? I'd be happy to merge it in. ctal doesn't appear to have this yet. I must have a look, of course any enhancement would be great - and since the main user at the moment is Jean-Marc, I would be interested in his opinion. 'ctal' is a somewhat confusing name by the way, you'd think it was TAL implemented in C, another interesting project I've dabbled with on and off in the past. I agree but if we change the name we should do it right now. What name (prefix) would you suggest? Only thing, it needs to be different from tal (since it must allow mixing the two namespaces in the same page) and I personally would also be against jtal. ctal was meant to stand for client tal but indeed it might not be the finest choice. -- Balazs Ree ___ 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: tal:define=... considered harmful?
Benji York wrote:
Martijn Faassen wrote:
Right, that was my motivation too - I googled around for
javascript-based templating languages but realized there wasn't
really anything. Of course XSLT can be used this way too, but TAL is
kinda neat too. Still, I couldn't think of much practical use for
this. Perhaps in this AJAXy world this has changed.
Personally I'm very excited about ctal (and like the name too).
Getting data objects from the server and feeding them to templates on
the client seems like a nice way to do AJAXy things.
yep, you can also use TAL (ZPT) to create CTAL templates; that's the
reason why I think the namespace is ctal:... and not tal:..., otherwise
it could as well have been called tal:... and the template be stored in
a string.
then there are different usage patterns,
personally I download the template from the server when the page is
getting initialized (using asynchronous Ajax.request) and I store the
source in a javascript variable in a widget class. To render the
template I apply the transformation whenever the data changes. It makes
it possible to refresh widgets, otherwise you'd have to refresh the page
or redo an Ajax.request.
here is the part of the code that does the rendering:
render: function(data) {
if (this.source) {
var node = document.createElement(div);
node.innerHTML = this.source;
ctal.process_ctal(node, data);
var old_html = this.widget.innerHTML;
var new_html = node.innerHTML;
if (new_html != old_html) {
this.widget.innerHTML = node.innerHTML;
}
}
}
the performance is quite fine actually, but since this is event-driven I
should first check that the data really has been changed before firing a
modified event, to avoid rendering the template for nothing.
I think 'ctal' is fine too. (client tal)
/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: Re: tal:define=... considered harmful?
Balazs Ree wrote: On Wed, 15 Feb 2006 16:41:36 +0100 Martijn Faassen wrote: A separate svn project would be nice. I'm sure z3lab is open; it's also welcome under the z3 base on codespeak. I will then check it in to one of those; seriously, I can't decide which location would be more proper as a home. The z3base seems more generic to me, however the other ajax stuff is already in z3lab. (except AZAX, which has the kukit part stored on codespeak.) I am facing the same decision at where to bring in the jsonserver (a.k.a. json-rpc) product which would be a complete zope2-zope3 product merge. sure, whatever Are you interested in recovering some of there Zope TAL based regex stuff from Sapling? I'd be happy to merge it in. ctal doesn't appear to have this yet. I must have a look, of course any enhancement would be great - and since the main user at the moment is Jean-Marc, I would be interested in his opinion. if it doesn't slow things down or add features that are not really needed, I think it's fine, but maybe an explanation would be good as to what it does? BTW one enhancement that I was thinking of was the ctal:attributes=... stuff, I find the i18n:attributes=... approach more intutive since it is possible to write code as if it was HTML first, insert the variables where they should be and then specify afterwards which attributes are to be replaced: a href=item/url ctal:attributes=href.../a instead of: a href= ctal:attributes=href item/url.../a (which removes an indirection) the ZPT tal:attributes=... syntax forces me to think to much but that's just a personal opinion I really think that the best way to add features is to create a sample applications and see what's missing in the language or what feels unnatural or too complicated to achieve, but basically if a missing feature forces you to move the logic to the data model, it is definitely not a missing feature. I believe that ZPT is too much of a scripting language. also I think that one namespace is enough (no context/title, request/user), but use title and user instead ... extra namespaces in a template are a sign that the view has not done a good job at preparing a data structure for the template to render it. 'ctal' is a somewhat confusing name by the way, you'd think it was TAL implemented in C, another interesting project I've dabbled with on and off in the past. I agree but if we change the name we should do it right now. What name (prefix) would you suggest? Only thing, it needs to be different from tal (since it must allow mixing the two namespaces in the same page) and I personally would also be against jtal. ctal was meant to stand for client tal but indeed it might not be the finest choice. that's what I guessed too, do I win something ? :-) /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: Last chance to comment on Simplify skinning
On Wed, Feb 15, 2006 at 03:39:02PM +0100, Philipp von Weitershausen wrote: Maybe I mean something different. I just want a folder in which I can drop all the files I want to customize (I love to customize), without registering something. That's not how it works in Zope 3, at least not right now and not by default. My proposal doesn't isn't addressing this. Shane has expressed an interesting idea that goes into the I just drop my stuff in here direction, but I'm frankly missing some important points in this idea yet. It might be interesting to develop it further, though. For now, however, we have to explicitly register everything. I consider that a good thing. I think it's an important use case, though. In CMF, annoying and limited as it was, installing a skin was a one-time job. Adding or removing resources in that skin was trivial. I think you don't care for the wrong reasons. You want your CMF experience duplicated. Perhaps you're not as bothered as I was with the CMF's limitations, but it sured annoyed me as hell having to create a new layer for every product I wrote for CMF. Yes, I didn't like that either. Neither do I like the current system. I have to explicitly register every one of my skin's 35 resources? This is a significant burden. I do that a lot more often than I create new products. I think what we're angling for is some way to register everything in a certain directory as resources with one directive. -- 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
Re: [Zope3-dev] Re: Re: tal:define=... considered harmful?
Balazs Ree wrote: On Wed, 15 Feb 2006 16:41:36 +0100 Martijn Faassen wrote: Are you interested in recovering some of there Zope TAL based regex stuff from Sapling? I'd be happy to merge it in. ctal doesn't appear to have this yet. I must have a look, of course any enhancement would be great - and since the main user at the moment is Jean-Marc, I would be interested in his opinion. Okay - I don't have a lot of time so I'd need to find first it to do work on this, but I'm quite excited that TAL in javascript is making a comeback, and it'd be nice if that old code of mine could serve a purpose in the future. :) 'ctal' is a somewhat confusing name by the way, you'd think it was TAL implemented in C, another interesting project I've dabbled with on and off in the past. I agree but if we change the name we should do it right now. What name (prefix) would you suggest? Only thing, it needs to be different from tal (since it must allow mixing the two namespaces in the same page) and I personally would also be against jtal. ctal was meant to stand for client tal but indeed it might not be the finest choice. Aah, now I understand where the 'c' comes from. What about 'btal', browser tal? 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: Re: tal:define=... considered harmful?
Jean-Marc Orliaguet wrote: Balazs Ree wrote: On Wed, 15 Feb 2006 16:41:36 +0100 Martijn Faassen wrote: Are you interested in recovering some of there Zope TAL based regex stuff from Sapling? I'd be happy to merge it in. ctal doesn't appear to have this yet. I must have a look, of course any enhancement would be great - and since the main user at the moment is Jean-Marc, I would be interested in his opinion. if it doesn't slow things down or add features that are not really needed, I think it's fine, but maybe an explanation would be good as to what it does? It basically does the same thing as ctal does, except less (no tal:repeat for instance, though I did have a simple tal:define), and it isn't going anywhere. I dabbled with it a few years ago as I thought it was an interesting idea and I just wanted to play a bit with javascript. It had unit tests, and the regex stuff that I was referring to may be interesting - it ports the regexes from Zope's TALES to Javascript so that the parsing of tales expressions works the same. This is the module that has the regex bits, ported directly, if I recall correctly, from Zope's python code: https://infrae.com/svn/sapling/trunk/zpt/talparser.js [snip] I really think that the best way to add features is to create a sample applications and see what's missing in the language or what feels unnatural or too complicated to achieve, but basically if a missing feature forces you to move the logic to the data model, it is definitely not a missing feature. I believe that ZPT is too much of a scripting language. Sure. I'm not sure whether the regexes are useful, just would be nice if they didn't go to waste after all. :) also I think that one namespace is enough (no context/title, request/user), but use title and user instead ... extra namespaces in a template are a sign that the view has not done a good job at preparing a data structure for the template to render it. Hm. If I'm rendering a bunch of records to a HTML table, say, I'd prefer my records to be in a list, and the records themselves give access to further details. More in general, it's possible that some template will receive two sets of data that's quite separate from each other. I like namespaces then too. You can of course always argue that such a template should be factored into multiple smaller ones, though the question remains how they'd each receive only their data and not the rest. 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: Last chance to comment on Simplify skinning
Paul Winkler wrote: I have to explicitly register every one of my skin's 35 resources? If the 35 resources (files) are in the same directory you can use the resource directory ZCML directive. Or am I missing something? -- Benji York Senior Software Engineer Zope Corporation ___ 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: Last chance to comment on Simplify skinning
On Wed, Feb 15, 2006 at 12:44:36PM -0500, Benji York wrote: Paul Winkler wrote: I have to explicitly register every one of my skin's 35 resources? If the 35 resources (files) are in the same directory you can use the resource directory ZCML directive. Or am I missing something? Only that I have the same question Martijn does: Can I then override one of those resources and keep the other 34? -- 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
Re: [Zope3-dev] Re: Re: tal:define=... considered harmful?
Martijn Faassen wrote:
if it doesn't slow things down or add features that are not really
needed, I think it's fine, but maybe an explanation would be good as
to what it does?
It basically does the same thing as ctal does, except less (no
tal:repeat for instance, though I did have a simple tal:define), and it
isn't going anywhere. I dabbled with it a few years ago as I thought it
was an interesting idea and I just wanted to play a bit with javascript.
It had unit tests, and the regex stuff that I was referring to may be
interesting - it ports the regexes from Zope's TALES to Javascript so
that the parsing of tales expressions works the same.
This is the module that has the regex bits, ported directly, if I
recall correctly, from Zope's python code:
https://infrae.com/svn/sapling/trunk/zpt/talparser.js
OK I see, it's the variable substitution;
string:${name}/${address} ..
the question is what this is not better computed in the model. If it's
just for presentation it's fine (e.g. adding a colon between two fields),
but then one could (even should) write:
span.../span: span.../span
but if the data is supposed to be a URL or something meaningful for the
entire application then there's a problem, because it's the template
that creates the data and the rest of the application has strictly no
access to it (at least in the MVC model where the view observes the
model and not the opposite).
[snip]
I really think that the best way to add features is to create a
sample applications and see what's missing in the language or what
feels unnatural or too complicated to achieve, but basically if a
missing feature forces you to move the logic to the data model, it is
definitely not a missing feature. I believe that ZPT is too much of a
scripting language.
Sure. I'm not sure whether the regexes are useful, just would be nice if
they didn't go to waste after all. :)
also I think that one namespace is enough (no context/title,
request/user), but use title and user instead ... extra
namespaces in a template are a sign that the view has not done a good
job at preparing a data structure for the template to render it.
Hm. If I'm rendering a bunch of records to a HTML table, say, I'd
prefer my records to be in a list, and the records themselves give
access to further details.
More in general, it's possible that some template will receive two
sets of data that's quite separate from each other. I like namespaces
then too. You can of course always argue that such a template should
be factored into multiple smaller ones, though the question remains
how they'd each receive only their data and not the rest.
Regards,
Martijn
what I mean it that the structures can always be merged before they are
passed to the template, then the data can be organized as:
data = {
items: [ ...],
people: [],
somemoredata: {}
}
ZPT does a mapping between several data structures (context, request,
view ...) and the variables with the same name in TAL, which results in
several namespaces. Such variables are very platform-dependent and a
templating language basically needs only one data structure to do the
rendering..
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: Zope 3 web root
Hello, I was thinking a lot about the proposed Zope3 web root, and the mentioned RDBMS first class citizenship. I'd like to backup an usecase and propose a somewhat different approach .. First of all, having the ZODB optional and mountable IMHO is a great thing, because it is not always needed, or even usable - imagine for example lots of accounting or statistical data, stored in millions of rows in a RDBMS, several years old, and presented using charts and grids. Moreover, I would and do design brand new Zope3 applications using SQL storage, not the ZODB, even when the storage is local to the filesystem (sqlite), just because I firmly believe, that the place for data is in the RDB, not in the ODB. Also because I couldn't find easy and effective enough way to get 20 objects out of 10 pieces in an ordered set, starting with number 27897 for example, but that's another story and may be entirely my fault as I didn't care to look very hard. But I know a lot of tasks, which the ZODB is much better suited for, especially if it did had that shiny little tool, capable of not only analyzing and displaying a stored object, but also changing it - it could spare me many minutes worth of restarting and waiting Zope to boot each day. It is on my todo list, you know, I just need some spare time. And the proposed indirection analyzer tool could spare some 2 months full of curiosity and curses as I slowly made my way trough let's say about 20% of that rapidly-changing-worst-documented-in-the-world big picture (not talking about Zope2, sorry guys, but although the more I learn, the more I love Zope3, it's not easy at all). Anyway, one of the strongest arguments against that web root in the filesystem is the Apache - why do we need Zope3 to serve files and directories out of the filesystem, and have those config files there, when we have a very sophisticated and solid tool, which does that more than fine and also a lot more, and more effectively than we can ever dream of with an interpreted language? You know, it wasn't the very next question that I asked myself, although it is so obvious, but eventually I got to it - well, why do we need Zope3 to parse HTTP requests while it generally and historically proved exists proxied behind this very tool, which is so much capable of parsing HTTP, and is also so flexible? Zope3 uses it's integrated twisted server to do everything about parsing protocols, but as I already said, we can't even dream of reaching the effectiveness of a heavy duty pure C/C++ HTTP machine which has decades of development and fine tuning behind, by using an interpreted language. And remembering the statement from it's own documentation, that Zope doesn't care much about what is in front, as long as it supplies the right object, then why not just mod_zope it ? And guess what .. There is that fundamental truth about Internet - it doesn't matter what idea just came to you, it is already there. Turns out that somebody is already doing it at http://codespeak.net/z3/modzope/ . So why not making it at least a bit more official and feature-complete? For example - capable of rendering page templates directly from the filesystem and mounting ZODBs .. Integrating with existing and proved solutions seems a lot more natural and trouble-proof, than doubling them and Apache has a lot that could be used in Zope. Regards, Velko Ivanov ___ 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 3 web root
Dario Lopez-Kästen wrote:
Sidnei da Silva said the following on 2006-02-14 12:15:
On Tue, Feb 14, 2006 at 08:17:04AM +0100, Dario Lopez-Kästen wrote:
| Shaun Cutts said the following on 2006-02-14 07:37:
| I have seriously considered trying out Django and similar tools to
see | if they would fit better with the kind of applications I need to
do, but | I really like the power that Zope as a platform offers, even
in Zope 2.
Then comes a question. Did anyone try reusing parts of Django inside
Zope 3?
I just would like it to be easier to work with Zope and {CMF or it's
successors} when data is not inside the ZODB.
The problem is that all the people used to LAMP will come to Zope and
think Well I will need to think differently here. Thats a bother. I
will use sql for everything like usual. And so we will get a lot of
duplicated efforts and half-baked Zope developers, who will desperately
try to use Zope for SQL development.
Remember its the Z Object Publishing Enviroment?
--
hilsen/regards Max M, Denmark
http://www.mxm.dk/
IT's Mad Science
___
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 3 web root
On 2/15/06, Max M [EMAIL PROTECTED] wrote: Remember its the Z Object Publishing Enviroment? Hear, hear! -- 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: Zope 3 web root
On Feb 15, 2006, at 4:21 PM, Lennart Regebro wrote: On 2/15/06, Max M [EMAIL PROTECTED] wrote: Remember its the Z Object Publishing Enviroment? Hear, hear! +1 (Which, to be clear, does not mean we shouldn't encourage people making it easier to use SQL in Zope. But our strength and heritage is as an OPE.) 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: One namespace for ZCML
Hi Philipp [...] Subject: Re: [Zope3-dev] Re: One namespace for ZCML Roger Ineichen wrote: I'm interessted in a menu / menu item refactoring. This means, we could get rid of the implicit magicly registred menus in other directives which ends in unaccessible menu items and will offer a better accessible API. I will write a proposal later, but perhaps I have to prototype first since this part is very complex and used almost in every browser directive. Note that my other proposal, ReducingTheAmountOfZCMLDirectives, mentions something like this in the end (it's not really part of the actual proposal anymore, just some random thoughts): Many directives of the browser namespace support the registration of menu items in addition to registering the component in question. Though this can be considered useful because it might save some typing, keeping directives as simple as possible (on/off switches!) might be weighed higher. People are certainly intimidated by the length of some of the browser directives (such as browser:editform); by taking the menu functionality out, we could reduce many directives by two lines making them easier to understand by themselves (of course, we'll have to add another menu directive, but it'll only be 3 or so lines). Yes, I agree, that's also a good base for a menu simplyfication. If you got any further comments on this, I'd be happy to hear them. It doesn't *have* to be a proposal, but it would sure be nice :). I think it's to complex it right now since I'm not sure at all if my idea will work. Let me try to give a short overview. - Merge the menu and menu item to one implementation - the above will also allow to implement nested menus. Right now the implicit menu, registred in views, don't have a id itself. This means they are unuseful for nested menu registrations. - move menu registration out of the view directives, (like described in your proposal) - Also refactor the IFactory concept. Use IFactory adapters on folders instead of IFactory utilities. The last part IFactory adapters instead of IFactory utilities depends on a application I wrote and was running in serious problems because of the slowdown which depends on IFactory utilies lookups. I'm not sure if somebody will agree on this, but I think if I can profile the IFactory utility implementation and show the slowdown, we have a better base for a proposal. This would also solve some namespace problems we have with the content type name registration. Note; nested menus are implemented since more then a half year. But they are not useable with the existing menu items which are registered inculded in the view directives. Because in the view directive registred menus are only menu items which are not nested. Regards Roger Ineichen Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Last chance to comment on Simplify skinning
On 2/15/06, Paul Winkler [EMAIL PROTECTED] wrote: Only that I have the same question Martijn does: Can I then override one of those resources and keep the other 34? Perhaps the resourceDirectory directive should just be sugar for a set of resource directives, one for each file in the directory? That would allow individual overrides, and maintain the convenience. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ 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 3 web root
Max M wrote: The problem is that all the people used to LAMP will come to Zope and think Well I will need to think differently here. Thats a bother. I will use sql for everything like usual. And so we will get a lot of duplicated efforts and half-baked Zope developers, who will desperately try to use Zope for SQL development. Because of this concern, I'm putting this off for a while. I think it addresses a major hole in Zope, but it also creates two ways to accomplish similar tasks without a clear division between the two ways. Note that the Python language, despite its philosophy, has at least two ways to accomplish things: with functions or with classes. In this case, two ways are definitely better than one, IMHO. But before Zope acquires a new way to create web sites, we need to better understand whether that's a burden Zope ought to bear. It could turn out that people who don't want ZODB really shouldn't use Zope at all. I would find that conclusion disheartening, but maybe it's realistic. Shane I think that the discussion about whether one could or should completely replace ZODB with SQL is less important than providing good connections to SQL while other things are done with ZODB. (After all -- python provides functions and classes, but it never says: either develop only with one or the other!) In my application it is perfectly clear (for the moment at least:)) what things are part of the UI/application interface (ZODB) and what things are data that needs ACID transactions, write-ahead logging and ODBC (Postgres). In general, many people who use relational databases do so for a good reason. I once worked on a project where we had to rip out ObjectStore after much frustration delay and expense for scalability reasons. What I'm having to write myself in this project, would have liked to have had, and perhaps wouldn't mind contributing to ZPL versions, are containers that allow one to open a window on the SQL world rather seamlessly. As it turns out, I've already done my object marshalling because our system has a Twisted/spread interface as well, so I didn't need SQL specific object marshalling (though a way of mapping annotations to DB would have been nice, as I hadn't included that in DB design). Rather, I just need containers that know that their contents live out there somewhere in a transaction based system that is itself responsible for object keys. - Shaun ___ 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: Last chance to comment on Simplify skinning
On 2/15/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: I find Zope 3's approach much simpler and much easier to explain than the CMF's approach. In Zope 3 (especially with my proposed changes in place), a layer is simply a label (read: marker interface) on the request. When we now look up pages and resources (e.g. images), we take the request into account and therefore inevitably that label. We will only find pages and resources associated (read: registered) for this label. Good news is that any page or resource can be associated for this label, we just have to remember to do that in their ZCML directive. When you say with my proposed changes in place, I don't understand how that differs from what currently exists, or what can exist. We at Bottlerocket started serious Zope 3 work with Zope 3.1. We've been defining skins and layers as Interfaces since that time. I didn't understand it entirely at first, but when I was debugging some issues that arose with a fix to multi-adapter lookup that came in Zope 3.2, I understood it more, and now it makes a lot of sense to me. So coming from that world, I'm not entirely sure I understand how your proposal is really different, except for this: In your proposal, 'Skins' are just gone as a separate concept - yes? What is now treated as a Layer can also be treated directly as a skin, yes? Here's a situation from a recent application of mine. The comments and doc strings are verbatim. Notice that I leave a number of breadcrumbs behind about which is the skin and which is the layer:: # Layer class KBase(IBrowserRequest): The ``kbase.skin.KBase`` **Layer** # Skin class KnowledgeBase(KBase, CMS, IDefaultBrowserLayer): The Knowledge Base Skin. Uses the CMS layer, but **not** rotterdam. The Knowledge Base skin is very specialized and does not need as many generic features as the Content Management or default ZMI skins. The primary dependance on the CMS layer is to get its resources (javascript libraries, icons). I assign most things in my application to the KBase layer. The KnowledgeBase Skin builds from three layers. Very early versions of this app did a mix of layers and skins in the bases used for ``KnowledgeBase``, but the skin it used brought in too many views that I didn't want interfering with things accidentally, so I went with the ``CMS`` layer instead so I'd get things from our CMS layer, but not get *everything* that was chosen for the *Content Management* skin. Does that make sense? If I understand your proposal correctly, the Layer and Skin above would both basically be the same thing, right? The only thing that I guess really differentiates them right now (in my application) is how they're registered in ZCML. But they're each the same basic collection of interfaces. ``KBase`` is shallow and dedicated to the browser view/resource components in my application, ``KnowledgeBase`` is rich and pulls in components from others. The only thing that I don't understand right now is this concept of Interface Types. I don't have our Zope 3 book in front of me right now, so I'm not sure if it has anything helpful to say. But I'll just say that Interface Types have been an elusive concept for me, so far. -- 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] Last chance to comment on Simplify skinning
On Feb 15, 2006, at 6:03 AM, Philipp von Weitershausen wrote: Hi there, a while back I wrote a proposal on simplifying the skinning system (http://dev.zope.org/Zope3/SimplifySkinning). I got a lot of useful feedback which in turn made me update the proposal. Since then I haven't heard much comments. I would like to start implementing it soon, especially since the time schedule has been moved up one month. Please speak up now if you got any remaining comments. Silence is assent :). I guess I'm +0 on your current proposal, and +1 on its goals. I like many parts of it. I didn't like the fact that the zcml ended up being longer. I didn't love that people had to start asking questions about interface types in order to register a skin. Interface types are a cost--another layer of abstraction, another potentially mind-blowing thing to explain. You are already suggesting changing the zcml, and I'd like to see a compromise between the brevity of the current zcml and the conceptual clarity of your proposed changes. I tried to brainstorm, but didn't love what I came up with. Maybe it can take us somewhere. What if we still deprecated browser:layer but kept a redefined version of browser:skin? Then your zcml-- interface interface=.interfaces.ShanghaiSkin type=zope.publisher.interfaces.browser.IBrowserSkinType / utility component=.interfaces.ShanghaiSkin provides=zope.publisher.interfaces.browser.IBrowserSkinType name=ShanghaiSkin / could become browser:skin component=.interfaces.ShanghaiSkin name=ShanghaiSkin / The rest of your example would remain the same. It doesn't accomplish everything you set out to do, and that's a shame, but it feels like a compromise with a reasonable counter- argument: defining skins is a basic task often introduced early on with teaching Zope, and it's a shame to have to bloat the zcml and teach advanced topics too soon. I'd like to at least get the interface... zcml out of this story. 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: Last chance to comment on Simplify skinning
On 2/15/06, Jeff Shell [EMAIL PROTECTED] wrote: I would prefer not. We've used resourceDirectory to support things like webcams. The image(s) uploaded by the cams might not always be there, but the containing path is. It's nice not having Zope start Good point. If it was sugar for a set of resource directives, this could easily fail out on us, unless it was making 'resource' items all the time whenever the directory's contents changed. Right. In which case, another possibility would be to have a new directive that really is just sugar as I described. That would avoid backward compatibility problems and make the intention clear. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ 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: Last chance to comment on Simplify skinning
Jeff Shell wrote: I find Zope 3's approach much simpler and much easier to explain than the CMF's approach. In Zope 3 (especially with my proposed changes in place), a layer is simply a label (read: marker interface) on the request. When we now look up pages and resources (e.g. images), we take the request into account and therefore inevitably that label. We will only find pages and resources associated (read: registered) for this label. Good news is that any page or resource can be associated for this label, we just have to remember to do that in their ZCML directive. When you say with my proposed changes in place, I don't understand how that differs from what currently exists, or what can exist. We at Bottlerocket started serious Zope 3 work with Zope 3.1. We've been defining skins and layers as Interfaces since that time. I didn't understand it entirely at first, but when I was debugging some issues that arose with a fix to multi-adapter lookup that came in Zope 3.2, I understood it more, and now it makes a lot of sense to me. Cool! So coming from that world, I'm not entirely sure I understand how your proposal is really different, except for this: In your proposal, 'Skins' are just gone as a separate concept - yes? What is now treated as a Layer can also be treated directly as a skin, yes? Yes, you are right, that's basically the only change my proposal advocates (and some minor details around it). Here's a situation from a recent application of mine. The comments and doc strings are verbatim. Notice that I leave a number of breadcrumbs behind about which is the skin and which is the layer:: # Layer class KBase(IBrowserRequest): The ``kbase.skin.KBase`` **Layer** # Skin class KnowledgeBase(KBase, CMS, IDefaultBrowserLayer): The Knowledge Base Skin. Uses the CMS layer, but **not** rotterdam. The Knowledge Base skin is very specialized and does not need as many generic features as the Content Management or default ZMI skins. The primary dependance on the CMS layer is to get its resources (javascript libraries, icons). I assign most things in my application to the KBase layer. The KnowledgeBase Skin builds from three layers. Very early versions of this app did a mix of layers and skins in the bases used for ``KnowledgeBase``, but the skin it used brought in too many views that I didn't want interfering with things accidentally, so I went with the ``CMS`` layer instead so I'd get things from our CMS layer, but not get *everything* that was chosen for the *Content Management* skin. Does that make sense? If I understand your proposal correctly, the Layer and Skin above would both basically be the same thing, right? Not necessarily. You're free to create whichever layer hierarchy suits you best. At some point you can then say that a particular layer in that hierarchy (typically one that combines a lot of other layers) becomes known under a human-readable name. We then say it's a skin. My proposal gives you the freedom to promote any layer to a skin. That means you can also register views directly for a skin because it's just another layer. You won't have to create a layer and then a skin based on that layer... The only thing that I don't understand right now is this concept of Interface Types. I don't have our Zope 3 book in front of me right now, so I'm not sure if it has anything helpful to say. But I'll just say that Interface Types have been an elusive concept for me, so far. Interfaces mark objects. Like This is a recipe or This is attribute-annotatable. Interface types mark interfaces. Like This is not just some interface, it's an interface for content components or This is an interface we use as a skin. When you got my book in front of you, look up the beginning of Chapter 5. Interfaces extend z.i.Interface. Interface types extend z.i.i.IInterface (notice the double I) because they describe interfaces. 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
[Zope3-dev] Re: Zope 3 web root
Max M wrote: The problem is that all the people used to LAMP will come to Zope and think Well I will need to think differently here. Thats a bother. I will use sql for everything like usual. And so we will get a lot of duplicated efforts and half-baked Zope developers, who will desperately try to use Zope for SQL development. Let us not worry about the half-baked developers but instead think about how the ideas in Zope itself can benefit a larger community of developers. Remember its the Z Object Publishing Enviroment? Has been around a while with ZSQL support and the net is littered with war stories about how people have burnt their fingers using Zope for SQL development. The mechanism of loading objects from the filesystem is going to set anybody back. My 2 paise, Suresh ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Last chance to comment on Simplify skinning
Hey Gary, thanks for your feedback. I like many parts of it. I didn't like the fact that the zcml ended up being longer. Me neither :(. I didn't love that people had to start asking questions about interface types in order to register a skin. Interface types are a cost--another layer of abstraction, another potentially mind-blowing thing to explain. Perhaps, perhaps not. I think the interface ZCML directive would be easy to understand by itself (Aha, so we register an interface. And we give it a type, like, what kind of interface it is.), but I'm totally biased. You are already suggesting changing the zcml, and I'd like to see a compromise between the brevity of the current zcml and the conceptual clarity of your proposed changes. I tried to brainstorm, but didn't love what I came up with. Maybe it can take us somewhere. What if we still deprecated browser:layer but kept a redefined version of browser:skin? Then your zcml-- interface interface=.interfaces.ShanghaiSkin type=zope.publisher.interfaces.browser.IBrowserSkinType / utility component=.interfaces.ShanghaiSkin provides=zope.publisher.interfaces.browser.IBrowserSkinType name=ShanghaiSkin / could become browser:skin component=.interfaces.ShanghaiSkin name=ShanghaiSkin / The rest of your example would remain the same. As you can imagine I'm a bit hesitant about having too many specialized ZCML directives like browser:skin. But I definitely see your point. I have the following compromise to suggest. The 'interface' directive is used for two things: * Registering an interface as a utility. For that it will use the dotted name of the interface. * Optionally putting a type on an interface. My suggestion is to add an optional 'name' parameter to it so that the interface won't necessarily have to registere using its dotted name. Then we can merge the 'interface' directive and the 'utility' directive from above into one. It will basically have the same affect as your suggested browser:skin directive and is only longer by the 'type' argument. interface interface=.interfaces.ShanghaiSkin type=zope.publisher.interfaces.browser.IBrowserSkinType name=ShanghaiSkin / Other usecases I see for the extra 'name' argument: Content Types. For example: interface interface=worldcookery.interfaces.IRecipe type=zope.app.content.interfaces.IContentType name=WorldCookery Recipe / So, this would be a very generic way of giving interfaces a type and name. Generic means that it'd be used throughout Zope extensions and would therefore provide a lot of consistency. It doesn't accomplish everything you set out to do, and that's a shame, but it feels like a compromise with a reasonable counter- argument: defining skins is a basic task often introduced early on with teaching Zope, and it's a shame to have to bloat the zcml and teach advanced topics too soon. I'd like to at least get the interface... zcml out of this story. I know my compromise does everything except that :). I think it's still better to keep consistency in the ZCML directives than having nicely sounding directives whose way of working isn't really explained just by their names. 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
