Re: [Zope3-dev] Re: Zope 3 web root
Shane Hathaway wrote: Page, File, Image, Python Page, SQL Script, and ZPT Page. I suggest that no one should be invited to create these kinds of objects in ZODB; it's a road to misery. I'm sorry, I simply don't agree. I find TTW development (especially with the aid of WebDAV) _exceedingly_ useful for small projects. The ability to make minor tweaks with nothing more than a web browser is often a godsend! 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] Re: Zope 3 web root
On Feb 18, 2006, at 3:08 AM, Shane Hathaway wrote: In my last project, reusing the ZMI seemed like a good idea. Maybe that was a bad choice. Do you start with an empty site.zcml? I haven't dared yet. :-) We started mostly from scratch, with various successes and failures as we tried to reuse large-scale UI/framework. I'd say that we've generally been happier and more successful reusing lots of small components and small-scale UI bits, versus large framework things like the ZMI (others with whom I work, feel free to disagree ;-). I regard the smaller zope 3 and eliminate zope.app movements as signs that this is a shared feeling. 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: Zope 3 web root
Gary Poster wrote: On Feb 18, 2006, at 3:08 AM, Shane Hathaway wrote: In my last project, reusing the ZMI seemed like a good idea. Maybe that was a bad choice. Do you start with an empty site.zcml? I haven't dared yet. :-) We started mostly from scratch, with various successes and failures as we tried to reuse large-scale UI/framework. I'd say that we've generally been happier and more successful reusing lots of small components and small-scale UI bits, versus large framework things like the ZMI (others with whom I work, feel free to disagree ;-). I regard the smaller zope 3 and eliminate zope.app movements as signs that this is a shared feeling. Ah-ha, that's a real nugget of wisdom. The ZMI as a whole isn't ready to be reused, then. In fact, the ZMI may not make sense at all for a lot of projects. I'll keep that in mind. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 web root
I just created mini-cms called GalleryMaker that allows a few web designer friends of mine to easily create and maintain websites for art galleries. It's a huge convenience for me to expose a few items TTW, like .css, some image files, and the contact page they are likely to swap out. Maybe this isn't part of the core, but I think there are a few good and manageable use cases for this. Chris Withers wrote: Shane Hathaway wrote: Page, File, Image, Python Page, SQL Script, and ZPT Page. I suggest that no one should be invited to create these kinds of objects in ZODB; it's a road to misery. I'm sorry, I simply don't agree. I find TTW development (especially with the aid of WebDAV) _exceedingly_ useful for small projects. The ability to make minor tweaks with nothing more than a web browser is often a godsend! 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/lists%40nabble.com -- View this message in context: http://www.nabble.com/Zope-3-web-root-t1094379.html#a3055165 Sent from the Zope3 - dev forum at Nabble.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: Zope 3 web root
Jeff Shell wrote: I guess I still don't understand how you're using Zope 3, because it sounds like you're using it very differently than I am. I've long since abandoned the ZMI. I never see that list of addable objects (in fact, in my newest applications, I completely bypass IAdding). I basically see the Zope 3 ZMI long enough to add one of my sites/applications. At that point, my skins take over, and that's all I see. The rotterdam skin is there as last resort to get out of trouble or to tweak local utility configurations. In my last project, reusing the ZMI seemed like a good idea. Maybe that was a bad choice. Do you start with an empty site.zcml? I haven't dared yet. :-) Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 web root
On Friday 17 February 2006 19:33, Shane Hathaway wrote: That sounds useful. In fact, doesn't this mean that we can safely move all TTW template and script authoring from Zope 3 into WebDev, where WebDev is a separately installable application? Probably yes. I think a proposal in this direction would find support. But please do not just move those content-level scripting objects into WebDev. WebDev is about TTW development in the site configuration space. BTW, during the snow sprint we did develop TTW pages and resources already, which was very cool. 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: Zope 3 web root
On Fri, Feb 17, 2006 at 10:14:50PM -0600, whit wrote: Paul Winkler wrote: +1. The killer moment for me with ZClasses was when I realized I wanted to convert one to a filesytem Product and that meant I had to literally throw away everything and start from scratch. Never again. now, if you could export all the behavior to sane fs code, would that moment still have been a killer? or would suddenly TTW just be another part of the toolchain? Yes. That would've been great. -- 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: Zope 3 web root
Shane Hathaway wrote: [snip] Yes, that's a valid point. I also stopped myself from listing folders, since a folder is a general organizational tool. Let's just talk about templates and scripts. [snip] I think I've got a decent use case for templates in the ZODB, but I could be wrong. I work for a large publishing company, and typically one of our applications will get installed on 40 or 50 sites within the same Zope instance, differing only in cosmetic ways. It seems like the logical thing to do here is to treat the templates as data and let them be edited TTW, limiting the coding level to 'presentation only'. -- Wade Leftwich Ithaca, NY ___ 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
Wade Leftwich wrote: Shane Hathaway wrote: [snip] Yes, that's a valid point. I also stopped myself from listing folders, since a folder is a general organizational tool. Let's just talk about templates and scripts. [snip] I think I've got a decent use case for templates in the ZODB, but I could be wrong. I work for a large publishing company, and typically one of our applications will get installed on 40 or 50 sites within the same Zope instance, differing only in cosmetic ways. It seems like the logical thing to do here is to treat the templates as data and let them be edited TTW, limiting the coding level to 'presentation only'. That can work, but be aware of the customers who customize more than you expect. They'll push the limits of the templates, and some of them might push so hard that they wind up creating a whole new framework based on your template API. You'll have to help them migrate their templates to new versions of your software, you'll have to put their templates under version control, you'll have to test new versions of your system with their templates, etc. I saw this pattern emerge several times at Zope Corporation, and I don't think it's specific to Zope 2. Maybe you can design a system that exposes a perfect, unchanging API to templates, but I'm pretty sure I can't. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 web root
Shane Hathaway wrote: Wade Leftwich wrote: Shane Hathaway wrote: [snip] Yes, that's a valid point. I also stopped myself from listing folders, since a folder is a general organizational tool. Let's just talk about templates and scripts. [snip] I think I've got a decent use case for templates in the ZODB, but I could be wrong. I work for a large publishing company, and typically one of our applications will get installed on 40 or 50 sites within the same Zope instance, differing only in cosmetic ways. It seems like the logical thing to do here is to treat the templates as data and let them be edited TTW, limiting the coding level to 'presentation only'. That can work, but be aware of the customers who customize more than you expect. They'll push the limits of the templates, and some of them might push so hard that they wind up creating a whole new framework based on your template API. You'll have to help them migrate their templates to new versions of your software, you'll have to put their templates under version control, you'll have to test new versions of your system with their templates, etc. I saw this pattern emerge several times at Zope Corporation, and I don't think it's specific to Zope 2. Maybe you can design a system that exposes a perfect, unchanging API to templates, but I'm pretty sure I can't. Shane We're supporting corporate users, so s/customers/coworkers/, but I see your point, and am interested in some of the less featureful templating alternatives being discussed -- meld3 et al. In Zope 2 our group follows the approach described by Stefan Holek in the tal:define considered harmful thread earlier today, and we put all the data the template is going to need into the options namespace. From Stefan's post: My take is that it's not the TAL features (tal:define, python:, whatever) that invite misuse, but the available namespaces. I have ported ZPT to Django [1][2] and found the experience surprisingly refreshing. Django naturally does not have anything like container or context in the Zope sense. And by Django policy, templates don't even get to see the request. The namespace Zope PTs call options becomes the sole, top-level namespace in Django PTs. This very effectively keeps me from pulling-in anything not provided by the view in the first place. Everything -- even functions I want to call in, say, conditions -- has to be added by the view. The result is clean and fast templates. -- Wade ___ 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
Jeff Shell wrote: I guess I still don't understand how you're using Zope 3, because it sounds like you're using it very differently than I am. I've long since abandoned the ZMI. I never see that list of addable objects (in fact, in my newest applications, I completely bypass IAdding). I basically see the Zope 3 ZMI long enough to add one of my sites/applications. At that point, my skins take over, and that's all I see. The rotterdam skin is there as last resort to get out of trouble or to tweak local utility configurations. Here here. I don't know how other people do it, but I expect to create an admin skin and a visitor skin which may or mayl not use the ZMI as a base. The ZMI isn't be-all-end-all of how an admin skin should be, it doesn't handle ajax and it's not made for frames. The ZMI should be optional. I don't want this to sound ranty, but it's a big assumption that a developer is going to use the ZMI. This assumption then bleeds into the ZCML where ZMI specific directives are sprinkled in all over the place. As a newbie, I found this very confusing ... what browser page am I really building for?? Kevin Smith -- View this message in context: http://www.nabble.com/Zope-3-web-root-t1094379.html#a3013423 Sent from the Zope3 - dev forum at Nabble.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: Zope 3 web root
Martin Aspeli wrote: On Thu, 16 Feb 2006 06:35:00 -, Shane Hathaway [EMAIL PROTECTED] wrote: No, we're still confused. Templates and scripts are code. Should they be in ZODB? Grrr, I hope not. I don't want to suffer that pain, fssync or no fssync. I invented the CMF skins tool primarily to pull a lot of templates and scripts out of ZODB. I invented Ape to pull them *all* out. Now I'm having trouble convincing myself to use Zope 3 because the problem has to be solved somehow yet again! I'm slightly confused too... when are you putting scripts and scripts in the ZODB? The books I read didn't tell me to do so User interfaces speak louder than books. Start up Zope 3, log in as a manager, and look at the list of things you can add. It includes DTML Page, File, Image, Python Page, SQL Script, and ZPT Page. I suggest that no one should be invited to create these kinds of objects in ZODB; it's a road to misery. We need rip them out and develop another way to fulfill the use cases they represent. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 web root
On Friday 17 February 2006 18:45, Shane Hathaway wrote: Martin Aspeli wrote: On Thu, 16 Feb 2006 06:35:00 -, Shane Hathaway [EMAIL PROTECTED] wrote: No, we're still confused. Templates and scripts are code. Should they be in ZODB? Grrr, I hope not. I don't want to suffer that pain, fssync or no fssync. I invented the CMF skins tool primarily to pull a lot of templates and scripts out of ZODB. I invented Ape to pull them *all* out. Now I'm having trouble convincing myself to use Zope 3 because the problem has to be solved somehow yet again! I'm slightly confused too... when are you putting scripts and scripts in the ZODB? The books I read didn't tell me to do so User interfaces speak louder than books. Start up Zope 3, log in as a manager, and look at the list of things you can add. It includes DTML Page, File, Image, Python Page, SQL Script, and ZPT Page. I suggest that no one should be invited to create these kinds of objects in ZODB; it's a road to misery. We need rip them out and develop another way to fulfill the use cases they represent. There is the WebDev effort that demonstrates some TTW development features that are actually applicable to Zope 3. Since WebDev concentrates on doing components, the results can later be easily exported to a filesystem package. 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: Zope 3 web root
Stephan Richter wrote: On Friday 17 February 2006 18:45, Shane Hathaway wrote: User interfaces speak louder than books. Start up Zope 3, log in as a manager, and look at the list of things you can add. It includes DTML Page, File, Image, Python Page, SQL Script, and ZPT Page. I suggest that no one should be invited to create these kinds of objects in ZODB; it's a road to misery. We need rip them out and develop another way to fulfill the use cases they represent. There is the WebDev effort that demonstrates some TTW development features that are actually applicable to Zope 3. Since WebDev concentrates on doing components, the results can later be easily exported to a filesystem package. What is the WebDev effort? Is it an application? A company? An event? Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 web root
On Friday 17 February 2006 19:03, Shane Hathaway wrote: There is the WebDev effort that demonstrates some TTW development features that are actually applicable to Zope 3. Since WebDev concentrates on doing components, the results can later be easily exported to a filesystem package. What is the WebDev effort? Is it an application? A company? An event? It is an experimental package to implement TTW development functionality for Zope 3. http://svn.zope.org/zope.webdev/trunk/ Roger is currently doing some development with it, since he has a need for a customer. Warning: The package is a little bit like the Wild West! 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: Zope 3 web root
Stephan Richter wrote: On Friday 17 February 2006 19:03, Shane Hathaway wrote: There is the WebDev effort that demonstrates some TTW development features that are actually applicable to Zope 3. Since WebDev concentrates on doing components, the results can later be easily exported to a filesystem package. What is the WebDev effort? Is it an application? A company? An event? It is an experimental package to implement TTW development functionality for Zope 3. http://svn.zope.org/zope.webdev/trunk/ Roger is currently doing some development with it, since he has a need for a customer. Warning: The package is a little bit like the Wild West! That sounds useful. In fact, doesn't this mean that we can safely move all TTW template and script authoring from Zope 3 into WebDev, where WebDev is a separately installable application? Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 web root
On Feb 17, 2006, at 6:45 PM, Shane Hathaway wrote: User interfaces speak louder than books. Start up Zope 3, log in as a manager, and look at the list of things you can add. It includes [...] File, [...] . I suggest that no one should be invited to create these kinds of objects in ZODB; it's a road to misery. We need rip them out and develop another way to fulfill the use cases they represent. To each his own, I suppose, but I'm surprised you included File in the rant-list. Lots of non-web-design uses want that. We've had our problems with big blobs, but they should be addressed, and in the core, and files should be probably included either in the core or as a well-maintained, highly-used, shared addition. As to the rest, while I think I understand at least a good chunk of the genesis of your statement, I'm glad that the component system *will* allow others to explore ZODB-based TTW dev as an add-on, as you suggested in a later message. You meant it in a derogatory sense, but one could argue that ZODB-based TTW dev got to be so problematic *because* it was so successful. There are strengths there. That said, I'm eager to see what you might think up as an alternative: I think both paths might be fruitful. Gary ___ 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
Paul Winkler wrote: On Thu, Feb 16, 2006 at 02:16:05AM -0700, Jeff Shell wrote: I think that Zope 2 suffered heavily from the too many ways to do it when it came to ways of doing development, and there were gulfs between each style. Each style had its plusses too. ZClasses certainly had an appreciative audience who liked defining schemas and building forms automatically through the web with little programming required. But working with templates and scripts in ZClasses had a bit of a different feel and behavior than working with those things in the 'content' space of the site. And it was very different than working with file system based products. +1. The killer moment for me with ZClasses was when I realized I wanted to convert one to a filesytem Product and that meant I had to literally throw away everything and start from scratch. Never again. now, if you could export all the behavior to sane fs code, would that moment still have been a killer? or would suddenly TTW just be another part of the toolchain? -w ___ 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
Gary Poster wrote: To each his own, I suppose, but I'm surprised you included File in the rant-list. Lots of non-web-design uses want that. We've had our problems with big blobs, but they should be addressed, and in the core, and files should be probably included either in the core or as a well-maintained, highly-used, shared addition. Yes, that's a valid point. I also stopped myself from listing folders, since a folder is a general organizational tool. Let's just talk about templates and scripts. As to the rest, while I think I understand at least a good chunk of the genesis of your statement, I'm glad that the component system *will* allow others to explore ZODB-based TTW dev as an add-on, as you suggested in a later message. You meant it in a derogatory sense, but Actually, I didn't. I only meant it in a separation-of-concerns sense. Incidentally, I find it difficult to make any argument about anything because I fully appreciate many sides of the issue. :-) one could argue that ZODB-based TTW dev got to be so problematic *because* it was so successful. There are strengths there. That said, I'm eager to see what you might think up as an alternative: I think both paths might be fruitful. The web root is my best idea for an alternative. Although I've been talking about addressing the needs of new adopters, I'm really trying to address *my* needs. I want to build a complex web site using Zope technologies, but I don't yet know enough about what I'm building to be able to do any model/view separation. I intend to write dirty, filthy, unmaintainable code. It's the right thing to do! If it works, I'll clean it up. If it doesn't, I'll throw it away and try something else. If I write it with Zope technologies, I know I can succeed at cleaning it up because Zope has the most powerful tools out there. If I write it with Apache, I'm certain I'll end up building my own framework to support whatever flavor of messiness the solution generates, it'll take twice as long, and it will be impossible to clean up, so I'll have to start over if I want it to last. Gimme Zope! While I'm writing messy code, I also invent messy processes along the way, and ZODB can't easily support my random new processes. I often write automated tests for messy code. I often think to myself, what is the ugliest possible way I can write this? Then I really do it and laugh. That gets me moving when I'm stalled. Sometimes I rewrite something ten times, relying on version control to get me back. It turns out that the CMF skins tool is much better at supporting this kind of work than Zope 3 currently is. I want Zope to encourage clean code just like everyone else, but interesting things rarely start out clean! If Zope wants to be a platform that people can use to invent crazy new things, it has to allow for messy code and processes. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 web root
On 2/17/06, Shane Hathaway [EMAIL PROTECTED] wrote: Incidentally, I find it difficult to make any argument about anything because I fully appreciate many sides of the issue. :-) You and me both :) Gary Poster: one could argue that ZODB-based TTW dev got to be so problematic *because* it was so successful. There are strengths there. That said, I'm eager to see what you might think up as an alternative: I think both paths might be fruitful. Personally, I like the idea of third party alternatives. I think one of the most extreme and interesting portlet style implementations is Seaside's halos. When they're turned on, from what I can tell from the few times I've looked at Seaside and related documentation, you have a lot of customization power. It's not for everybody. But I think it's an implementation that personalizes Zope 2 style Through The Web capability by localizing what you edit to the component that you see. http://blogs.inextenso.com/seaside/blog/learning/0cf6f89c-7824-11d8-81ca-000a27b05150 http://www-128.ibm.com/developerworks/opensource/library/os-lightweight8/ CSS, HTML, and Smalltalk Source for everything is accessible - but it's accessible *in place*, not buried in a completely foreign interface or buried deep within a master template or script... It's still object oriented. Fascinating. But as I said earlier, this is something that Smalltalk's image oriented development supports (where all of the code lives inside a virtual machine/environment, away from any concept of files). The ZODB *can* behave like this, but that only works best if all concept of code-in-the-ZODB-image is separate from any-kind-of-data that might be in it. Anyways, that's an aside. It's not something I nor any of my customers need. But it would be an interesting thing to see someone take up. The web root is my best idea for an alternative. Although I've been talking about addressing the needs of new adopters, I'm really trying to address *my* needs. I want to build a complex web site using Zope technologies, but I don't yet know enough about what I'm building to be able to do any model/view separation. I intend to write dirty, filthy, unmaintainable code. It's the right thing to do! If it works, I'll clean it up. If it doesn't, I'll throw it away and try something else. If I write it with Zope technologies, I know I can succeed at cleaning it up because Zope has the most powerful tools out there. If I write it with Apache, I'm certain I'll end up building my own framework to support whatever flavor of messiness the solution generates, it'll take twice as long, and it will be impossible to clean up, so I'll have to start over if I want it to last. Gimme Zope! While I'm writing messy code, I also invent messy processes along the way, and ZODB can't easily support my random new processes. I often write automated tests for messy code. I often think to myself, what is the ugliest possible way I can write this? Then I really do it and laugh. That gets me moving when I'm stalled. Sometimes I rewrite something ten times, relying on version control to get me back. It turns out that the CMF skins tool is much better at supporting this kind of work than Zope 3 currently is. I want Zope to encourage clean code just like everyone else, but interesting things rarely start out clean! If Zope wants to be a platform that people can use to invent crazy new things, it has to allow for messy code and processes. Where doesn't it allow this? I wrote about this in Griddle Noise earlier this week. I feel more free to mercilessly restructure in Zope 3. I feel free to write things crappy or mediocre initially. Most of our big projects have been done under hard deadlines and technical debt was accrued along the way. But much of that debt was easy to pay back, sometimes with just a day or two of postmortem reconstructive surgery. How is the skins tool better than actual Python classes as view objects? They're still on the file system. They can still be under version control. The page templates are still on the file system. They can still be under version control. I guess I still don't understand how you're using Zope 3, because it sounds like you're using it very differently than I am. I've long since abandoned the ZMI. I never see that list of addable objects (in fact, in my newest applications, I completely bypass IAdding). I basically see the Zope 3 ZMI long enough to add one of my sites/applications. At that point, my skins take over, and that's all I see. The rotterdam skin is there as last resort to get out of trouble or to tweak local utility configurations. I guess I've just made some supporting libraries and frameworks to help me. I had this with Zope 2 too, but it's been easier to do with Zope 3. I encourage everyone to do this. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub:
[Zope3-dev] Re: Zope 3 web root
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shane Hathaway wrote: Jeff Shell wrote: I agree that better integration with external data should be a priority for Zope. But what does that mean? In theory, if something's a Python object it should work with Zope 3 with relative ease... If that's not the case, perhaps we need to look at how much work is required to take some random Python object that may be created by some random data access library and get it into a Zope 3 published web page. If it kicks and screams and resists security and interfaces, or what not, maybe we need to take a look at all of that. Let me focus the discussion: I think it's nearly always a bad idea for anyone, newbie or expert, to put a template or script in ZODB. Do we have any agreement on that point? I wish we did. I enjoy ZODB for many purposes, but not for storing templates and scripts. I have a real client application where the templates themselves *are* the content being managed: they are *not* software. They *must* be stored in the ZODB. You could think of these things as active content components, or somthing, and they are not logically the same thing as stock templates used for software, but they do include ZPT. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD9Jni+gerLs4ltQ4RAmrjAKCiwoNHJd8ZTKqnJ+8FemITlPuQtwCfZ3nC QxO8Etxh2cyrUIMb7tcvzE4= =KLiU -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 web root
Chris McDonough wrote: On Feb 15, 2006, at 11:52 PM, Jeff Shell wrote: A Zope that was basically zope.publisher, zope.component, zope.interface, zope.schema, and tal/tales (and maybe 'transaction') would be ideal. +1 I guess this is all kindof rambling. I just don't see any benefit to me. I'd rather see any effort like this pick up the zope.bobo branch/product or whatever it is right now and deliver a clean and simple stripped down zope publisher that could run on WSGI and could be used to show up all of those but i can make a wiki in twenty minutes tutorials and have no dependence on storage of any kind. +1 +1 +1. Did I mention +1? - C +1 to that ___ 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: 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
[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] Re: Zope 3 web root
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 do not know; in reality I have to confess that I have not had the time
to do things with neither Zope3 nor Django, I have only thought about
and tried to weigh pros and cons based on my own experiences with Zope 2
and by reading what others have reported.
What I feel is that there is a gap between the kind of applications that
I need to build and the requirements that the current set of Zope 2
tools have about the underlying architecture. I can see how the tools
themselves have good, solid functionality whose value if apparent even
for non-content applications but the very tight ties to the ZODB for
everything makes it harder than necessary to interact outside the
boudnaries that exist.
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.
/dario
--
-- ---
Dario Lopez-Kästen, IT Systems Services Chalmers University of Tech.
Lyrics applied to programming application design:
emancipate yourself from mental slavery - redemption song, b. marley
___
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 13, 2006, at 5:36 PM, Martin Aspeli wrote: On Mon, 13 Feb 2006 07:51:34 -, Chris Withers [EMAIL PROTECTED] wrote: Scripts and RBDMS are the fast food of the web development world, not the salad. Looks nice, tastes great, eventually leaves you fat and unhealthy. ZODB and maybe an ORM is the greens for me, it might not be to everyone's taste at first, but it's the best option in the long run... I think that's certainly true for content-centric applications, which is what people seem to build the most of in Zope. But if you were storing 80 million records of numbers and short strings that you needed to query across multiple dimensions, you'd probably put them in postgresql. Zope 3 should really have a better story on SQL. Not replace the ZODB, but show how in your code you best deal with an RDBMS. I think that should leverage existing python APIs and ORM tools (I think there's a place for both SQL-style queries and ORM, depending on how much you need ad-hoc queries or at least complex, one-off representations of data, and how much you need one logical view of your data), but there should be patterns and integration layers (if needed) to show how to get data from an RDBMS into a view, how to make an edit form for that data, and how to integrate that with the rest of your probably content-centric application. FWIW, I like this Zope RDBMS vision. Gary ___ 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 Mon, 13 Feb 2006 07:51:34 -, Chris Withers [EMAIL PROTECTED] wrote: Scripts and RBDMS are the fast food of the web development world, not the salad. Looks nice, tastes great, eventually leaves you fat and unhealthy. ZODB and maybe an ORM is the greens for me, it might not be to everyone's taste at first, but it's the best option in the long run... I think that's certainly true for content-centric applications, which is what people seem to build the most of in Zope. But if you were storing 80 million records of numbers and short strings that you needed to query across multiple dimensions, you'd probably put them in postgresql. Zope 3 should really have a better story on SQL. Not replace the ZODB, but show how in your code you best deal with an RDBMS. I think that should leverage existing python APIs and ORM tools (I think there's a place for both SQL-style queries and ORM, depending on how much you need ad-hoc queries or at least complex, one-off representations of data, and how much you need one logical view of your data), but there should be patterns and integration layers (if needed) to show how to get data from an RDBMS into a view, how to make an edit form for that data, and how to integrate that with the rest of your probably content-centric application. 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: Zope 3 web root
Martin, Here here! I'm just learning to cross the gap starting from the RDBMS side. Just our initial deployment will have a DB growing by about 30K numbers per day, day in and day out. There are various workflows that are driven by this data. The parts of these that need people are now supposed to be available via Zope3. In my case, the business logic is in python, so I don't need (or want) to access the db directly, but I do need hollow, paged containers that live in the ZODB themselves but display data that lives elsewhere. I've started implementation, (... stumbling along so far... any comments on: Re: [Zope3-Users] newbie design questions for UI to external data would be welcome!) - Shaun -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Aspeli Sent: Monday, February 13, 2006 5:37 PM To: zope3-dev@zope.org Subject: [Zope3-dev] Re: Zope 3 web root On Mon, 13 Feb 2006 07:51:34 -, Chris Withers [EMAIL PROTECTED] wrote: Scripts and RBDMS are the fast food of the web development world, not the salad. Looks nice, tastes great, eventually leaves you fat and unhealthy. ZODB and maybe an ORM is the greens for me, it might not be to everyone's taste at first, but it's the best option in the long run... I think that's certainly true for content-centric applications, which is what people seem to build the most of in Zope. But if you were storing 80 million records of numbers and short strings that you needed to query across multiple dimensions, you'd probably put them in postgresql. Zope 3 should really have a better story on SQL. Not replace the ZODB, but show how in your code you best deal with an RDBMS. I think that should leverage existing python APIs and ORM tools (I think there's a place for both SQL-style queries and ORM, depending on how much you need ad-hoc queries or at least complex, one-off representations of data, and how much you need one logical view of your data), but there should be patterns and integration layers (if needed) to show how to get data from an RDBMS into a view, how to make an edit form for that data, and how to integrate that with the rest of your probably content-centric application. Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/shaun%40cuttshome.net ___ 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] 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
[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: Zope 3 web root
Chris Withers wrote: A big -1 from me. This is yet more complexity and more stuff that Zope shouldn't try to do. If you want to serve flat files, use Apache. From my understanding this is not only about serving flat files. OTOH I think that it may be possible to make Apache to do this: Let's add some ZCML directives that define how to interpret filenames in the web root by their extension. 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. 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: Zope 3 web root
On Thu, 09 Feb 2006 18:40:51 -, Shane Hathaway [EMAIL PROTECTED] 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 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. 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? Part 3: One kind of file we can put in the web root serves as a gateway into an object database. Or use RewriteRules? Martin P.S. I would be more excited if there was a similarly integrated story for RDBMS. P.P.S. I think Zope is great in large part because of the ZODB, not in spite of it P.P.P.S. I agree that having alternate ways of storing information is attractive ___ 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 Fri, Feb 10, 2006 at 11:30:29PM -, Martin Aspeli 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? Because you want to use adapters? :) One idea I want to try some time is making Zope 3 WSGI application work on Apache or IIS. http://isapi-wsgi.python-hosting.com/ -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.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: Zope 3 web root
Martin Aspeli wrote: On Thu, 09 Feb 2006 18:40:51 -, Shane Hathaway [EMAIL PROTECTED] 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 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. 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. 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? P.P.S. I think Zope is great in large part because of the ZODB, not in spite of it I agree. P.P.P.S. I agree that having alternate ways of storing information is attractive Yup. Figuring out exactly how to do that, though, has proven hard. :-) 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
On Thu, Feb 09, 2006 at 11:40:51AM -0700, 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.
[..]
| Any thoughts or gut reactions?
My first response was cool.
My second response was: that's apache; zope isn't supposed to compete
with or replace apache.
After reading the other responses, I can definitely see real value in
zope supporting applications that don't need an object store. I did
create an app that (apart from being TTW because I didn't know better
at the time) is entirely RDB-based, another app that uses the zodb for
configuration only and is otherwise entirely backed by LDAP, and I
have created or thought of some applications that don't need any
persistence at all (beyond configuration data, which could be zconfig
or zcml). This definitely has a lot of value.
So I'm in generally in favor and would like to see an experiment on a
branch like Stephan suggested. My only concern is that it could grow too big
and try to become an apache replacement.
-D
--
\begin{humor}
Disclaimer:
If I receive a message from you, you are agreeing that:
1. I am by definition, the intended recipient
2. All information in the email is mine to do with as I see fit and make
such financial profit, political mileage, or good joke as it lends
itself to. In particular, I may quote it on USENET or the WWW.
3. I may take the contents as representing the views of your company.
4. This overrides any disclaimer or statement of confidentiality that may
be included on your message
\end{humor}
www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED]
signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 web root
On Fri, Feb 10, 2006 at 04:49:55PM -0700, Shane Hathaway wrote: | Martin Aspeli wrote: | On Thu, 09 Feb 2006 18:40:51 -, Shane Hathaway | [EMAIL PROTECTED] wrote: [...] | 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. FWIW apache does this too. I did some experiments with a script that would take a .rst (ReStructuredText) file and generate the HTML on the fly and put a handler in apache's config. | It's a rapid prototyping tool and a gentle | entry into the world of Zope. It's the other scenarios that make it more interesting. Also having the possibility of the long-running zope process to manage session state and other stuff like that for you. -D -- He who scorns instruction will pay for it, but he who respects a command is rewarded. Proverbs 13:13 www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
