Re: [Zope3-Users] Re: [Zope3-dev] Visionaire! (All your problems, solved)
Martijn Faassen wrote at 2006-3-3 18:13 +0100: Martin Aspeli wrote: On Thu, 02 Mar 2006 11:49:31 -, Lennart Regebro [EMAIL PROTECTED] wrote: This should be Zope3 as it is now. A couple of things can go away. Maybe the rotterdam skin, I don't know. Definitely the default Folder objects and such. People, especially Zope2 people, think that you are supposed to use them. You aren't, you are supposed to build your own. Yeah, why the hell are there there then? ;-) I like the default Folder objects and use them. Building your own is a waste of time if they do exactly what you want. Windows, Windows 98/NT/ME/CE/2000/2003/XP, I hear of Avalon/Longhorn as names for future .Net based Windows versions. Similar (although not that many) variations for Office (Office 98/2000/2003). You can find drastic changes in the technology names (rather than the product names): e.g. COM, OLE, ActiveX, COM+ -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-Users] Re: [Zope3-dev] Visionaire! (All your problems, solved)
On 3/4/06, Dieter Maurer [EMAIL PROTECTED] wrote: You can find drastic changes in the technology names (rather than the product names): e.g. COM, OLE, ActiveX, COM+ This is a silly pseudo-discussion, but I continue it for fun. ;-) COM, OLE and ActiveX are not the same thing. COM is an object component model, OLE is an extension of that for document objects, and ActiveX is a set of technologies of which COM and OLE are some. It's not exactly a drastic name change of what is basically the same. Maybe MS have done that from time to time, but it's definitely not something they do very often. Examples of when things have changed name is when PCMCIA changed name to PC-card. They have had to live with both names forever. I can't think of any product wh has had a successful name change after it's widespread release. -- 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-Users] Re: [Zope3-dev] Visionaire! (All your problems, solved)
Martin Aspeli wrote: On Thu, 02 Mar 2006 11:49:31 -, Lennart Regebro [EMAIL PROTECTED] wrote: This should be Zope3 as it is now. A couple of things can go away. Maybe the rotterdam skin, I don't know. Definitely the default Folder objects and such. People, especially Zope2 people, think that you are supposed to use them. You aren't, you are supposed to build your own. Yeah, why the hell are there there then? ;-) I like the default Folder objects and use them. Building your own is a waste of time if they do exactly what you want. 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] Visionaire! (All your problems, solved)
I like this a whole lot. This is *much* better than diluting the Zope brand (Zed is dead, baby). If people really say things like Oh, I can't use zope.testbrowser because I'm not using Zope it's time to school them, not to ruin our brand: You only need the Zope CA for that, dude, so stop whining. Zope already worked when people like the RoR creators attended primary school. The term Zope having a bad rap in some circles is not Zope's fault, and can not be fixed by calling it Zed (to the contrary, I'd think). IMO, Stefan On 2. Mär 2006, at 01:42, Jeff Shell wrote: - Zope 3 CA: The Zope Component Architecture. Core services. Would include zope.publisher and most other current top level zope.* things. Usable as a library, as a publisher for other environments, perhaps as a simple standalone server. Easy to deploy against WSGI, Paste.deploy, whatever. - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack using the ZODB, ILocation, and most of the zope.app services but without any content objects. Perhaps only an application server configuration skin (process management) but no ZMI. Maybe have the current configuration installable as an option. - Zope Suite (or Zope Web or Zope DE): This is the full application server perhaps Jim is envisioning. A comprehensive web based user interface, based on features (and implementations) of both Zope 2 and Zope 3 application servers and offerings. -- Anything that happens, happens. --Douglas Adams ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Visionaire! (All your problems, solved)
The idea has some benefits, but I'm not very sure it's a good idea. If it should be implemented, this is how I would like to see it: On 3/2/06, Jeff Shell [EMAIL PROTECTED] wrote: - Zope 3 CA: The Zope Component Architecture. Core services. Would include zope.publisher and most other current top level zope.* things. Usable as a library, as a publisher for other environments, perhaps as a simple standalone server. Easy to deploy against WSGI, Paste.deploy, whatever. No, I don't think it should be easy to deploy against anything in. It should be so stripped down that it isn't about web anymore. No server. Just the component architecture. The component architecture is a great architecture even for non-web development. zope.interfaces, .components, .i18n*, .testing. Maybe even .configuration and .thread? Now, if you want to use the CA for web deployment, but not the whole Zope, you can easily add the publisher and pagetemplates and so on to your toolstack. But the component architecture is NOT about web. - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack using the ZODB, ILocation, and most of the zope.app services but without any content objects. Perhaps only an application server configuration skin (process management) but no ZMI. Maybe have the current configuration installable as an option. This should be Zope3 as it is now. A couple of things can go away. Maybe the rotterdam skin, I don't know. Definitely the default Folder objects and such. People, especially Zope2 people, think that you are supposed to use them. You aren't, you are supposed to build your own. - Zope Suite (or Zope Web or Zope DE): This is the full application server perhaps Jim is envisioning. A comprehensive web based user interface, based on features (and implementations) of both Zope 2 and Zope 3 application servers and offerings. I don't see a need for this. I think this level should be the end product, ie, Plone 3, CPS4, Silva Something. A midlevel Suite with which you still can't do shit without development seems pointless. Separate product packages like ecm support, and Zope2 backwards compatibility and such makes sense. The Suite does not. -- 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] Visionaire! (All your problems, solved)
On Thu, 02 Mar 2006 11:49:31 -, Lennart Regebro [EMAIL PROTECTED] wrote: This should be Zope3 as it is now. A couple of things can go away. Maybe the rotterdam skin, I don't know. Definitely the default Folder objects and such. People, especially Zope2 people, think that you are supposed to use them. You aren't, you are supposed to build your own. Yeah, why the hell are there there then? ;-) 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] Visionaire! (All your problems, solved)
We've been through a lot lately. You know it, I know it. Zope has a reputation. Sometimes it's good, sometimes it's bad. This has affected Zope 3, since Zope 3 is very much not Zope 2. But it's affecting Zope 2 as well, as Jim has brought to our attention. Zope 3 is Mature. Zope 3 sounds like Zope 2+1. Zope 2 and Zope 3 have very different concepts. Zope 3 has restricted its audience, for now, to developers; while Zope 2 is appealing to many different kinds of end users and programmer types. Five offers a bridge so that Zope 3 as a library may be used in Zope 2, and the Zope 2 core has started making use of some Zope 3 concepts. But it's obvious we have a name problem. Even within Zope 3, there's a name problem, between Zope 3 as Application Server and Zope 3 as cool collection of packages. Today, I wrote a much longer message in response to the Two Visions thread. But I was in a bit of a bad mood, having spent many hours trying to set up a test harness to test one little thing in my own code that was causing problems - a one little thing that depended on quite a few components being set up, and it was painful. And I'm still not done. And I realized, as I stewed away, that I like Zope 3 as an Application Server... But I'd like it with less. And this option hasn't been proffered, so far as I can tell. It seems like Jim's Vision might be two options - zope as library and big zope application server with all of the object file system and probably through the web stuff and so on and so on and would be largely compatible with both Zope 2 and Zope 3 as they stand today. Personally, I'd love to have the first option. I also, personally, don't care if I have the second option, but I recognize the need or desire for it, and the desire to get out the message that Zope 2 and the applications on it actually do have a future even though they may not have a future with Zope 3 as Zope 3 is currently known. I'd like a third option: the Zope 3 Application Server as it is right now, but with less. No Rotterdam skin, perhaps no ZMI. No content objects at all, except maybe for some example file and image objects to show how to do BLOBs. It would still be ZODB based. It would still be ILocation based. zope.app.container would be prominent, and zope.app.folder would not be a distraction. It's the basis for building applications like Schoolbell/Schooltool, custom content management, itinerary managers, knowledge bases, whatever. Catalog, local sites/utilities, all still there. But without the distraction of should I support the ZMI? use it as my user interface? should I use the TTW page templates?. IFolder and IContainer... What is the difference and which should I use? Which should be my base class (because at Bottlerocket, we chose Folder when we shouldn't have, we found out much later). Maybe that stuff would still be in the library. Maybe it would still be available as a 'mkzopeinstance' option. But the Zope 3 Application Server would probably work best if it promoted custom development via persistent objects, views, and custom skins, as the default way of working with it. It's easier to write documentation for, it could be easy to write mkzopeinstance commands for (to generate a basic starting point with skeleton code and a site.zcml setup that loads the custom skin). There's not this other User Interface and other objects providing a distraction. I'm making a wiki. How does SQL Script apply? I18N File?. And then I thought about Taligent, for some reason. I'm not going into the history of the company/project, whose products never really made it out into the light of day. But at some point, they broke their product (which was to be a new object oriented operating system) out into a small set of distinct offerings: TalOS (Taligent Object Services), TalAE (Taligent Application Environment), and so on. And I thought about doing this for Zope, and came up with the following: - Zope 3 CA: The Zope Component Architecture. Core services. Would include zope.publisher and most other current top level zope.* things. Usable as a library, as a publisher for other environments, perhaps as a simple standalone server. Easy to deploy against WSGI, Paste.deploy, whatever. - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack using the ZODB, ILocation, and most of the zope.app services but without any content objects. Perhaps only an application server configuration skin (process management) but no ZMI. Maybe have the current configuration installable as an option. - Zope Suite (or Zope Web or Zope DE): This is the full application server perhaps Jim is envisioning. A comprehensive web based user interface, based on features (and implementations) of both Zope 2 and Zope 3 application servers and offerings. We don't need a hundred different editions like Microsoft. Nor do we need a hundred different acronyms like Java development seems to have. I think we could boil things down to these three offerings,
Re: [Zope3-dev] Visionaire! (All your problems, solved)
Jeff Shell wrote: - Zope 3 CA: The Zope Component Architecture. Core services. Would include zope.publisher and most other current top level zope.* things. Usable as a library, as a publisher for other environments, perhaps as a simple standalone server. Easy to deploy against WSGI, Paste.deploy, whatever. - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack using the ZODB, ILocation, and most of the zope.app services but without any content objects. Perhaps only an application server configuration skin (process management) but no ZMI. Maybe have the current configuration installable as an option. - Zope Suite (or Zope Web or Zope DE): This is the full application server perhaps Jim is envisioning. A comprehensive web based user interface, based on features (and implementations) of both Zope 2 and Zope 3 application servers and offerings. That's quite appealing, IMHO. Could you agree with the following distinction? - Zope 3 CA expects the model (and the method of persisting the model) to be completely defined by the Python programmer. - Zope 3 AS expects most of the model to be stored in ZODB and implement ILocation. However, it still expects model objects to be defined by the Python programmer. - Zope Suite (great name, BTW) defines a complete but limited model. It is a simple content management system (like Zope 2 + CMF) that's easily extended in countless ways. Does that match what you're suggesting? I'd hate to misrepresent your vision. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Visionaire! (All your problems, solved)
On 3/1/06, Shane Hathaway [EMAIL PROTECTED] wrote: Jeff Shell wrote: - Zope 3 CA: The Zope Component Architecture. Core services. Would include zope.publisher and most other current top level zope.* things. Usable as a library, as a publisher for other environments, perhaps as a simple standalone server. Easy to deploy against WSGI, Paste.deploy, whatever. - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack using the ZODB, ILocation, and most of the zope.app services but without any content objects. Perhaps only an application server configuration skin (process management) but no ZMI. Maybe have the current configuration installable as an option. - Zope Suite (or Zope Web or Zope DE): This is the full application server perhaps Jim is envisioning. A comprehensive web based user interface, based on features (and implementations) of both Zope 2 and Zope 3 application servers and offerings. That's quite appealing, IMHO. Could you agree with the following distinction? - Zope 3 CA expects the model (and the method of persisting the model) to be completely defined by the Python programmer. Yes, although Zope 3 CA could also be used in non-web environments (I've used it in an internal package manager experiment, for example). I'd like the Zope 3 CA download to include some useful examples and/or skeletons (possibly configured for Paste Deploy) to show some of the different options - use with SQLObject, other template packages (page templates would be included with the core though), etc. It could also include some other publisher/publication objects that could show integration with tools like Routes, for example. These extras would be outside of the core library, of course. For purposes of documentation and evangelizing, the Zope 3 CA can provide improved documentation about core Zope concepts like object publishing, without having to put Zope 3 AS expectations or terms on the programmer, giving them an entry point to the larger world of the Zope Application Servers without being overwhelming. Then we (or someone else) can write Python on What Have The Romans Ever Given Us, which would show how you can do a rails programming by convention style system using the component architecture. The CA would automatically create adapters/views to bind ``models/person.py``, ``controllers/person.py``, and ``views/person/list.pt`` together. How those adapters are registered and used by the publisher would show off the CA. - Zope 3 AS expects most of the model to be stored in ZODB and implement ILocation. However, it still expects model objects to be defined by the Python programmer. Yep. Zope 3 AS might also yield a solid foundation of base interfaces to allow easier use of 'sqlos' and/or 'sqlalchemy' backed objects that still provide a core set of useful and usable information (dublin core, etc), and could offer the option of using one of those instead of the ZODB while providing the caveat that use of other (third party) 'model' components may require additional work to map. Essentially, Zope 3 AS would be the option for those who like the Zope 3 + ZODB way. So many of these other web 'frameworks' with their O-R mappers show off applications that don't really need the full power of SQL. If you don't need it, why go through it? The ZODB is very credible - perhaps more so now than ever. Zope 3 AS would also downplay or replace the ZMI. I think there should be a skin available for configuration - ie, for adding a site (a complete application like Schoolbell, a customer CMS, etc) and maybe giving access to configuration options, like the stuff in ++etc++site, but that's it. I think the current ZMI suffers from being both a system administrator tool and application / data entry tool. I know that security settings can filter out a lot of the administrative features, but the interface that's left still feels a bit incomplete. And it raises the question should I provide for it? should I define some zmi_menu menu items, just to be useful? should I use it as my user interface? Django is killing us on automatic data (not system) administration pages. If web based configuration/administration (add a site, set up users, maybe select that site's skin, flush caches; process administration) was separated, then someone could build and provide something like Django's admin screens or Turbogear's Catwalk for doing the data entry. But it would be an option to use that as a view/skin/tool, and clearly marked as such. Some applications, like many CMS's, need something like the ZMI as they often separate the concept of data entry/management from how it is presented to the site's visitors. But an application like Schoolbell or a Knowledge Base may have just one skin. All data entry, display, etc, is managed through that. Having to support (or wonder about supporting) the ZMI shouldn't be a concern of those applications. It's just a point of removing
Re: [Zope3-dev] Visionaire! (All your problems, solved)
On Mar 1, 2006, at 11:02 PM, Jeff Shell wrote: [...] Django is killing us on automatic data (not system) administration pages. [...] I didn't follow this, probably because I don't know Django. Do you mean they excel in automatic data entry forms, a la Zope 3 edit forms/ formlib? As in Ruby-on-Rails slick SQL-driven AJAX forms? Or...? Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
