[Zope3-dev] Re: Re: Who would use this crazy thing called Zope 3?
On Sat, 11 Feb 2006 10:39:52 -, Lennart Regebro [EMAIL PROTECTED] wrote: things. Extreme example: In Plone the core Plone product is called CMFPlone. It pisses Alexander off. Should we rename it 'Plone' and thus break every product that ever imported from CMFPlone? Should we make a jungle of aliases and deprecation warnings? Or should we live with our mistakes? In this case, the benefit is marginal and the potential confusion and breakage is high. That trade-off point moves with time, though, as the more major parts of the framework become right and as the user base increases. However, that same user base will not increase beyond those who are so well-informed that they know what they're getting themselves into, if the software gets a reputation for breaking your code. I guess the question is, how far along that curve is Zope 3? How far along does it want to be? It's curvature point is 6.3 milliMartins. ;-) Hah :) There are methods for neatly deprecating things like this, and they have been employed consitently in Zope 3, and quite consistetly in later versions of Zope2. For example, in Zope 2.8 the whole Zope package was renamed Zope2. The Zope.py backwards compatibility handler will be removed in Zope 2.11. I'm not aware of this causing any problems. There are two types of deprecation, though - one is deprecating specific packages or methods or classes. Another is deprecating fundamental patterns and ways of working. Am I supposed to use ZCML for this or Python? Well, a while ago, it was ZCML, now it's python, and then maybe it'll be something that looks completely different. Now I'm told that the ZODB is the de-facto way of storing content. Maybe soon the default may be a filesystem. Mmm... I just wonder how someone who isn't already in the know and on this list would hope to keep up with all these twists and turns. That is - I wonder how those who have deployed on Zope 3 deal with them. Martin -- (muted) ___ 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: Who would use this crazy thing called Zope 3?
On 2/11/06, Martin Aspeli [EMAIL PROTECTED] wrote: There are two types of deprecation, though - one is deprecating specific packages or methods or classes. Another is deprecating fundamental patterns and ways of working. Am I supposed to use ZCML for this or Python? Well, a while ago, it was ZCML, now it's python, and then maybe it'll be something that looks completely different. Eh, no, that's not a fundamental pattern. Declaring an object to be an adapter in ZCML or in Python are not two different ways of working. ZCML is hardly gonna go away completely, and neither is python. ;-) Now I'm told that the ZODB is the de-facto way of storing content. Maybe soon the default may be a filesystem. Mmm... Mmm, sure. -- 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: Re: Who would use this crazy thing called Zope 3?
On Feb 11, 2006, at 9:24 AM, Martin Aspeli wrote: I'm told that the ZODB is the de-facto way of storing content. Maybe soon the default may be a filesystem. Mmm... My feelings are that there should be a classic Zope 3 release which is exactly what exists now (it should make the assumption that ZODB is present and the root object of the publication lives there, present a management interface, etc.) and there should be a light Zope 3 release which is really just BoboNG which makes no assumptions about the publication object. Jim did some work on this last year. IMO, this would be Zope 3 without anything that currently lives in zope.app. The reason for the light version would be to make it easier for people who don't necessarily buy in to the ZODB or schema-based content or through the web management, etc. to start using Zope gradually without needing to bite all of it off at once. I think the filesystem-traverser Shane is referring to might be packaged as a plugin to one of these versions or the other. It would just be a package which defines the publication root object as a filesystem traverser. Making it optional and shipping it separately from Zope 3 would decouple things appropriately, IMO. - C ___ 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: Who would use this crazy thing called Zope 3?
Martin Aspeli wrote: Now I'm told that the ZODB is the de-facto way of storing content. Maybe soon the default may be a filesystem. Mmm... Whatever we do with the filesystem, it's not going to be as ambitious as Ape. Ape makes the filesystem appear as an object database, but that turns out to be more complexity than most people want. I think it'll be more similar to CMF DirectoryViews. Scripts and templates on the filesystem that want to read/write data will probably use an object database or RDBMS. Shane ___ 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
I really like this idea. I spend most of my time developing applications with Plone, and am just starting to use zope 3. Most of what I spend my time on is site customisation and one off development. But I've never really found a nice way to layout my applications, Product (or more standard python modules now in zope 3) development doesn't really seem a good fit. With this system I can see my site as: root/ index.zpt (customised homepage, no longer living in the zodb yay!) contacts/ index.zpt contactsdb.zodb projects/ index.zpt projectsdb.zodb ... So I get to move my site customisation to the filesystem in a more natural way than a python module allows. Yes, it looks a bit like an apache site, but hell, I know apache, and I'm building a website :-) As an aside, I've just been doing a little mod_python development and in some ways it seems very natural using it for small applications, but I miss all the zope goodies. I think this could really open up zope 3 to more developers, so a big cheer from me. Laurence Shane Hathaway wrote: An idea just occurred to me. I think others have probably had similar ideas, but didn't express it in the right place or time. Part 1: Let's put an Apache-like web root (similar to /var/www/localhost/htdocs/) in Zope instance homes. It might be called browser or www. Zope will serve pages out of that web root rather than an object database. Part 1 rationale: When people create a Zope instance home, they create some config files and an object database. The root of the site is served out of the object database. To change the default page, newbies are directed to create a default page in the object database. The user didn't ask for an object database. The use of an object database should be a choice, not a requirement. Now the user has to learn some extra tools (fssync, etc.) in order to put the files under version control. I think the user experience for both newbies and experts would be much better if the root of the site were served from a filesystem directory. Part 2: Let's add some ZCML directives that define how to interpret filenames in the web root by their extension. Let's also interpret special per-directory files that map URI names to filenames, similar to Apache .htaccess files. Part 3: One kind of file we can put in the web root serves as a gateway into an object database. We might use the extension .zodb for this purpose. The .zodb file would specify what kind of storage to open, where to find it, and what object to load from it. In a sense, the web root would mount the object database. Some configuration of the web root would mount an object database right at the root, enabling Zope 3 to act just like it does today. Any thoughts or gut reactions? Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] tal:define=... considered harmful?
Hi! 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. For the record MochiKit also has something equivalent called MochiTAL that supports tal:content and tal:repeat. Anyway, CTAL implements all familiar instructions (tal:repeat, tal:condition, tal:omit-tag, tal:replace, tal:attributes) except one which is ... tal:define. There is also the equivalent of python:... which naturally becomes javascript:... I almost felt that something was missing, because I'm so used to inserting tal:define in page templates. But now I realize that this is a mistake. There was a discussion recently on the list about python expressions being a bad idea, think twice I would say that tal:define is much worse: When writing templates, the temptation is great to insert a tal:define to pull some data into the view which is not directly available in the model represented by the view. But the idea with a template is that it should represent some data using some markup. The data is supposed to be already available in some context. If the presentation layer needs to cook some extra data, it means that there isn't enough presentation data in the first place. Also in a situation where serveral views observe the same model, all views must have access to the same information. A view cannot hold a private data layer. Some argued that python expressions in ZPT are bad. Why are they? If there is no tal:define to put the expressions into what can go wrong? The question about separating presentation from data has nothing to do with *how you access the data* ( via tal:content=item/url or via tal:content=python: item['url'] ) it has to do with *where you put the data*. here is the test file to get an idea of what CTAL can do: http://svn.z3lab.org/trac/z3lab/file/cpsskins/branches/jmo-perspectives/ui/framework/tests/unit/cpsskins_ctal_test.html best /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Pluggins vs Application Definition
Some recent discussions on the distutils-sig mailing list have helped me to understand some issues related to the ways we extend the Zope application server. Traditionally, in Zope 2, you extended Zope by dropping product packages into a special Products package. This was very convenient in many ways, but doesn't always provide enough control or visibiity to what's going on. 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. I've noticed that at Zope Corporation, for our customer projects, we tend not to use package-includes. We prefer to explicitly include packages we use directly oin our application ZCML files. (As applications, may be composed of several layers, we may include things at multiple levels.) In thinking about this, I realized that there are two different users here with different concerns: - Application developers need to build an application. They will generally want fairly tight control over what goes into the application. For them, it's valuable to say in an explicit way what they want. - If the application is extensible, then application users will want to be able to extend the application by adding pluggins. 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. In summary, I think we need *both* approaches, as they serve different needs. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Re: Zope 3 web root
On Fri, 10 Feb 2006 23:49:55 -, Shane Hathaway [EMAIL PROTECTED] wrote: So, I'm serving static content like Apache, I'm interpreting file types like Apache and I'm using .htaccess files like Apache. But I'm using Zope. Why am I not just using Apache? Would I be learning this beast that is Zope? The content is not necessarily static. If you drop a .zpt file in the directory, and some ZCML has mapped .zpt to PageTemplateFile, the result is generated on the fly. It's a rapid prototyping tool and a gentle entry into the world of Zope. You're using Zope because your friends recommended it or it's because you already know it. You believe that the prototype can evolve fairly easily into a Python package, if you later need it. If you have friends who recommend Zope, you are probably already quite familiar with Zope ;-) But ... if this is about offering an alternative for the content/run-time-configuration-space ZODB, why would you encourage putting ZPTs and Python scripts there? Isn't that a step back to the Zope 2 days, where content and logic got intermixed in the same database? Part 3: One kind of file we can put in the web root serves as a gateway into an object database. Or use RewriteRules? RewriteRules only work externally. One possible use of a .zodb file is to mount a catalog or an object store, which requires an internal reference. P.S. I would be more excited if there was a similarly integrated story for RDBMS. Are you saying you want to put code and templates in an RDBMS, that you want content to be stored in an RDBMS, or that you want to talk to an RDBMS without putting SQL scripts in an OODBMS? No, not at all. But I don't to put code or templates in the ZODB either, I want to put them in python modules. I would like the option of storing my content in an RDBMS more transparently, possibly via some ORM mapping like SQLAlchemy so that it's transparent to me as the python developer. I have no idea if it's technically feasible, but imagine how great it would be if deriving form Persistent and configuring that particular class via some ZCML directive as being RDMBS-stored with a given OR mapping (to map my fields to a particular datbase schema, much like Hibernate does in the Java world) simply made that class be stored in the RDBMS. And I'd like to make it easier to talk to RDBMS' in Zope, although I think libraries like SQLOS or SQLAlchemy sound like nicer paths to that end as opposed to having Zope invent something of its own (not that I've used either, of course, I've only read a bit). Anyway, didn't mean to hijack your thread. However, a similar story for on-filesystem content storage would be interesting, although that would require some sort of marshalling technology (storing python pickles in files is not that interesting, since it's still a black box). I suppose the WebDAV file representations of objects that exist today would work just as well on the filesystem, though. Martin -- (muted) ___ 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
On Fri, 10 Feb 2006 16:56:23 -, Shane Hathaway [EMAIL PROTECTED] wrote: Wade Leftwich wrote: +1 from the standpoint of promoting corporate adoption, especially when combined with first-class citizenship for RDBMS. (In the corporation I work for, anyway.) Yes, RDBMS would become a first-class citizen. New users would be able to write some page templates and SQL scripts on the filesystem and have them work with no extra effort. I know I'd like that capability myself. However, I expect ZODB to continue to be the dominant platform for writing Zope applications, because ZODB is quite productive for writing abstract applications. Zope is a feast with many kinds of food. When people come to the feast, most are not willing to try everything at once, particularly the entrees from the land of OODBMS. First let them have some familiar foods. When they find out how finely prepared the food is, they'll be ready to try the meaty main course. Although many will still prefer the RDBMS salads. I think this is an interesting idea, and I certanly like the goal of lowering the bar of entry. However, I wonder if we're not just proposing two fundamentally orthogonal ways of working. One uses python modules with logic in adapters, views on objects with page templates etc. that all operate on content objects in an object store. Another a hierarchy of page templates or static pages and mounted databases. This latter way of working is lot more like the traditional model that's found in anything from PHP to JSF, and quite frankly is therefore probably easier to swallow. But would it at the same time integrate well with the rest of the Zope world, and with arguably better ways of working? And how difficult would it be to move from one model to the other? Honestly, I don't know the answer. I'm neither for or against your proposal, I just want to understand it, because I *want* to like it - I want to see Zope leverage more of the technologies and environments people from the outside world are used to working in. -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 web root
Shane Hathaway wrote: Zope is a feast with many kinds of food. When people come to the feast, most are not willing to try everything at once, particularly the entrees from the land of OODBMS. First let them have some familiar foods. When they find out how finely prepared the food is, they'll be ready to try the meaty main course. Although many will still prefer the RDBMS salads. Sometimes the ZODB (the OODBMS you speak of) isn't appropriate for the environment your app will live in. Many apps aren't stand-alone.. they need to integrate and share data with other systems. Most of those systems already know how to use an RDBMS, so the path of least resistance is to use one of those. I'm sure the ZODB is probably the best solution for most applications that are stand-alone, Zope only - but as soon as you need to start architecting a complex set of tools that all interoperate an RDBMS seems like a better idea. ... or perhaps I'm simply suffering from RDBMS brain-damage, after using them for so long. ___ 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
Jim Fulton wrote: In summary, I think we need *both* approaches, as they serve different needs. I'd have to agree... so +1 .. but I'd suggest that the application/plugin should have a way of defining which ways it can (or prefers, if it can't be enforced) to be included, so it is clear that Package-X is really a plugin for Product-Y, rather than a whole new stand-alone product. rob ___ 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
Shane Hathaway wrote: Any thoughts or gut reactions? For the record, my gut reaction: Very interesting idea! I think there are two parts to the rationale here: 1) Making it easy to quickly prototype an app on the filesystem using methods that people are familiar with. You mention that above. I think people like PHP programmers would be very familiar with this development model. I'm not sure if we should make them feel at home with Zope 3. I rather would make Python people feel at home first. I also wonder: How you would evolve a small app built this way to a larger app that properly lives in Python packages? I guess you would have to put a lot of effort into converting the .py files to proper Python modules and the ZCML files to properly register browser pages and the like. This might still be a small price to pay when you're data model doesn't have to change, but it feels like Zope would encourage a more unpythonic development model for beginners and small apps than it would for large apps built by experts. To lower the barrier for Zope development, I would personally like to put more thought into the zope.bobo approach: Coming from pure Python prototyping you factor more things out into ZPT, ZCML and adapters until you end up with an application layout that we have today. This would be very gradual, something that I'm still lacking to see in your approach. 2) The ZODB should not be the only first-class citizen. This part of the rationale has become apparent in this thread. Your interesting idea certainly steers into that direction, but it doesn't have to be the sole solution to improve the RDBMS story in Zope 3. I think, it would really help if the default Zope 3 distribution shipped without the ZODB. That means it would also ship without content types, local site support, etc. If you wanted all that, you could still install the necessary packages for the ZODB and the rest later. The only point is: Zope 3 apps should not need to require the ZODB if they don't use it. I don't think it's entirely possible today (I remember Sidnei talking about a lot of pain). I hope that the use of eggs will allow us to make this very easy, both for the people who don't need the ZODB Co. and the ones who do. 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: Who would use this crazy thing called Zope 3?
Chris McDonough wrote: I'm told that the ZODB is the de-facto way of storing content. Maybe soon the default may be a filesystem. Mmm... My feelings are that there should be a classic Zope 3 release which is exactly what exists now (it should make the assumption that ZODB is present and the root object of the publication lives there, present a management interface, etc.) and there should be a light Zope 3 release which is really just BoboNG which makes no assumptions about the publication object. Jim did some work on this last year. IMO, this would be Zope 3 without anything that currently lives in zope.app. The reason for the light version would be to make it easier for people who don't necessarily buy in to the ZODB or schema-based content or through the web management, etc. to start using Zope gradually without needing to bite all of it off at once. +1 In fact, I would go as far as calling the light version Zope 3. If you want more (the ZODB, etc.) then you just need to install those extension packages to Zope 3. As said in a different post to the list, I think the use of eggs would make this a lot easier and could help justifying the additional step you need to take go get a classic Zope 3 installation. I'm not entirely convinced that the line we'd have to draw between classic and light Zope is exactly at the zope.app border now. zope.app also contains non-ZODB specific things that Zope 3 should still ship with. Which again shows how stupid the zope vs zope.app distinction is. Death to zope.app! 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: Pluggins vs Application Definition
Jim Fulton wrote: Some recent discussions on the distutils-sig mailing list have helped me to understand some issues related to the ways we extend the Zope application server. Traditionally, in Zope 2, you extended Zope by dropping product packages into a special Products package. This was very convenient in many ways, but doesn't always provide enough control or visibiity to what's going on. 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. I've noticed that at Zope Corporation, for our customer projects, we tend not to use package-includes. We prefer to explicitly include packages we use directly oin our application ZCML files. (As applications, may be composed of several layers, we may include things at multiple levels.) In thinking about this, I realized that there are two different users here with different concerns: - Application developers need to build an application. They will generally want fairly tight control over what goes into the application. For them, it's valuable to say in an explicit way what they want. - If the application is extensible, then application users will want to be able to extend the application by adding pluggins. 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. In summary, I think we need *both* approaches, as they serve different needs. I agree with all of the above, but fail to see what your implication is. I think we have all that now. Sure, we're not dropping Zope 3 plug-ins into a special directory but really anywhere in PYTHONPATH. Whether that additional freedom makes it easier is debatable, but I'd say we're still burned from Zope 2 wrt fixed drop-in locations. Frankly, I think something like ez_install zope.reallycoolstuff is even easier than manually dropping stuff. As for the package-includes slug, a simple ez_install-like tool could help there as well. I sketched it out once on a blog post: http://www.z3lab.org/sections/blogs/philipp-weitershausen/2006_01_11_mata-los-productos 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: Selecting a code name
Martijn Faassen wrote: Just to drop a note that I think a discussion about a potential brand name for Zope 3 is far less important than actually fixing our website and presenting Zope 3 (and Zope 2 for that matter) in a better way. Perhaps we can better redirect our energies to that than to have long (but easy, as everybody can say something without having to do anything) discussions about something that in the end isn't going to matter that much. Yes, thank you :). Now I don't have to catch up with this insanely long thread. Zope 3 already has a recognized brand as a rewrite of Zope 2 in the community - let's go with that. Indeed. Plus, I strongly feel that pushing Zope 3 more than Zope 2 or viceversa isn't helping. We need to push Zope-the-technology and Zope-the-community. Branding Zope 3 and making it look like something separate now when Zope 2 is actually moving towards Zope 3 feels like a step back. Let's promote Zope. 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: Nine new ZC Zope 3 packages
Martijn Faassen wrote: With a package in the 'zope' namespace, what am I supposed to do when I install it? Symlink it into lib/python of my Zope 3 software home? For the record: no. You can simply have multiple directories for a namespace package when you use 'pkgutil'. See http://python.org/doc/current/lib/module-pkgutil.html. So you'd have SOFTWARE_HOME/lib/python/zope and also INSTANCE_HOME/lib/python/zope. 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: Selecting a code name
On Feb 11, 2006, at 11:48 PM, Philipp von Weitershausen wrote: [...] Indeed. Plus, I strongly feel that pushing Zope 3 more than Zope 2 or viceversa isn't helping. We need to push Zope-the-technology and Zope-the-community. Branding Zope 3 and making it look like something separate now when Zope 2 is actually moving towards Zope 3 feels like a step back. Let's promote Zope. Unfortunately, very few of us appear to agree on what Zope 3 is, let alone what Zope is. 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: Selecting a code name
Gary Poster wrote: On Feb 11, 2006, at 11:48 PM, Philipp von Weitershausen wrote: [...] Indeed. Plus, I strongly feel that pushing Zope 3 more than Zope 2 or viceversa isn't helping. We need to push Zope-the-technology and Zope-the-community. Branding Zope 3 and making it look like something separate now when Zope 2 is actually moving towards Zope 3 feels like a step back. Let's promote Zope. Unfortunately, very few of us appear to agree on what Zope 3 is, let alone what Zope is. What does Jim say Zope and Zope 3 are? Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
