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
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
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
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
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
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
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: [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
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
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
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 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-de
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 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
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 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 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 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
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
Shane Hathaway wrote: It could turn out that people who don't want ZODB really shouldn't use Zope at all. This has been the case in my experience... 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
Martin Aspeli wrote: 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. That depends. If the data is heirarchical, I'd stick with ZODB. IF I cared about seamless rollback I'd stick with ZODB. If I cared about a uniform storage for all data to do with a project, I'd stick with ZODB... 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. Yup, not gonna argue with any of that, if only for integrating with legacy systems... 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
> Max M wrote: > > The problem is that all the people used to LAMP will come to Zope and > > think "Well I will need to think differently here. Thats a bother. I > > will use sql for everything like usual." And so we will get a lot of > > duplicated efforts and half-baked Zope developers, who will desperately > > try to use Zope for SQL development. > > Because of this concern, I'm putting this off for a while. I think it > addresses a major hole in Zope, but it also creates two ways to > accomplish similar tasks without a clear division between the two ways. > Note that the Python language, despite its philosophy, has at least > two ways to accomplish things: with functions or with classes. In this > case, two ways are definitely better than one, IMHO. > > But before Zope acquires a new way to create web sites, we need to > better understand whether that's a burden Zope ought to bear. It could > turn out that people who don't want ZODB really shouldn't use Zope at > all. I would find that conclusion disheartening, but maybe it's > realistic. > > Shane I think that the discussion about whether one could or should completely replace ZODB with SQL is less important than providing good connections to SQL while other things are done with ZODB. (After all -- python provides functions and classes, but it never says: either develop only with one or the other!) In my application it is perfectly clear (for the moment at least:)) what things are part of the UI/application interface (ZODB) and what things are data that needs ACID transactions, write-ahead logging and ODBC (Postgres). In general, many people who use relational databases do so for a good reason. I once worked on a project where we had to rip out ObjectStore after much frustration delay and expense for scalability reasons. What I'm having to write myself in this project, would have liked to have had, and perhaps wouldn't mind contributing to ZPL versions, are containers that allow one to open a window on the SQL world rather seamlessly. As it turns out, I've already done my object marshalling because our system has a Twisted/spread interface as well, so I didn't need SQL specific object marshalling (though a way of mapping annotations to DB would have been nice, as I hadn't included that in DB design). Rather, I just need containers that know that their contents live "out there somewhere" in a transaction based system that is itself responsible for object keys. - Shaun ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: 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 ___ 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
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 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
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 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? -- 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
correction (Re: [Zope3-dev] Re: Zope 3 web root)
Dario Lopez-Kästen said the following on 2006-02-14 08:17: If the tools and feature that Zope provide become easier to integrate in an non-Zope envireonment, I think that Zope will eventually come out as the tool of choice for any projects that needs to do more than "setup a simple website", which in my experience amounts to about 80% of the use cases out there :-). Sorry, I was a bit unclear here. What I mean is * if the features that zope provides become easier to use (in circumstanses where you would consider other toolkits over zope because the traditional Zope-way of doing things becomes an obstacle), * then zope may eventually become the tool of choice for any projects that need more than setting up a simple website. In my experience, virtually any site/application that does not serve static files starts growing requirements. Because the customer's needs and ideas grow with the capabilities of the solution, eventually "the simple website" winds up being a more or less advanced application. Thus, the feature-set of Zope becomes truly usable even in non-ZODB-centric applications. /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
Shaun Cutts said the following on 2006-02-14 07:37: 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: I have very similar needs, though in my case I want to use Zope as the GUI-engine and value-adder for a lot of integration work we do. 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. In an ideal world, Zope can be used as a toolkit for *applications*, not just content-centric solutions. Lots of the features that zope2/3 has make a lot of sense in terms of designing applications in general, even outside the content-centric mind-box. If the tools and feature that Zope provide become easier to integrate in an non-Zope envireonment, I think that Zope will eventually come out as the tool of choice for any projects that needs to do more than "setup a simple website", which in my experience amounts to about 80% of the use cases out there :-). So I think that Shanes proposal is a step in the right direction. My 0.02 SEK /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
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
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
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
