On 2/16/06, Shane Hathaway <[EMAIL PROTECTED]> 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 agree, generally. For one customer, we (sparingly) use page templates in the content space of the ZODB. But those are usually only just one or two lines. Nothing fancy, nothing programmatic. But also not a situation that would require a special view object in that space. Other than that - I completely agree. Your proposal just sounds like you want to have things like we had in Zope 2, but as pages and scripts on the file system that are executed/rendered semi-automatically. And that seems like it comes back to a problem that existed with Zope 2. Ignoring the ZODB for the moment, there's just a bit of a gulf between "templates and scripts" and "browser view classes/components". > The obvious question is, "if templates and scripts are special enough to > not belong in ZODB, what else is so special?" It's really hard to say. > In fact, I can think of rare situations where I actually do want to > put templates and scripts in ZODB. Well, anything can theoretically be stored in the ZODB. You can put scripts and binary images into an RDBMS just as easily. Whether that's a good idea is a separate issue. 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. If there's one (and only one) dominant way of developing for Zope 3, that story is easier to tell. Do you want to make things "easier" for "newbies" by telling them "well, you can just put some scripts and templates on the file system, it's that easy!" and "well, if you want to really develop properly for Zope 3, you need to do this..."? That's where I think this "web root makes things easier for newbies" argument falls apart. If you want to do scripts and SQL on the file system, there are lots of other options that do the job better than us. I think we have more important things we could spend the energy on. On the other hand, if I've completely mis-interpreted your initial proposal, feel free to ignore all of the above. > At one extreme, ZClasses tested the hypothesis that everything, > including code, belongs in ZODB. I think experience has proven that > hypothesis wrong. The persistent code idea in Zope 3 tries to give > ZClasses a new birth, but it seems to have turned out even more > complicated than ZClasses. There are certainly advantages that can be gleamed from image-based development. I've seen some really impressive things done with Seaside. But Smalltalk (and its developers) are used to that kind of environment. It's less natural for Python. If persistent code doesn't behave quite like regular Python code, then there's still a gulf that has to be crossed when one wants to "move up" from persistent code. So yeah, I agree - not everything belongs in the ZODB. I agree vigorously! And that's what I'm arguing in favor of. It's so easy now to just have: class Article(Persistent, Contained): tags = () body = u"" And bam - articles! No translation layer, nothing. Put those in the ZODB and go to town happy. > That eliminates the two extremes, so there's no need to talk about those > anymore. We have to choose what belongs in ZODB and what doesn't, and > the decision is often important but not easy. I think that the decision only gets important when one is concerned about optimization of writes, reads, etc. IE - when does one really want the ZODB, and when does one want an RDBMS because it has better disk access or backup tools or supports a kind of ad-hoc querying needed by a particular application? I guess I saw that templates and scripts are there in the Rotterdam skin. I seldom even see that skin any more so I guess I just don't notice. I think I tried using a 'through the web' script once in Zope 3, and had absolutely no idea what objects I could even refer to. Making my own persistent objects, skins, views, etc, was just the obvious way to go when I started seriously using Zope 3 that I've never honestly thought that another way was still being seriously offered. It's been so easy, so uniform, whether doing a simple application, a complex one, or a simple beginning to what could grow into a larger and more complicated application. There's been just one obvious way to do it, as far as I'm concerned. The results we've been able to achieve have been staggering. > I think the distinguishing feature of templates and scripts that makes > them poor candidates for storage in ZODB is the fact that their life > cycle is almost completely independent of the life cycle of a typical > object database. When I'm wearing the software developer hat, my > templates and scripts get packaged and shipped, but my test database > doesn't. When I'm wearing the web developer hat, my templates and > scripts go through a staging process, but my test database doesn't. > Zope doesn't have or want the infrastructure that would be required to > package, ship, and stage complete object databases. Exactly. All my views and templates are, well, views. They're all on the file system. "Scripts" are methods of view objects. Or functions. Or whatever. They're all software. They have been since I started Zope 3 development. My object databases may be test data, or they may be real content being prepped to ship out (which is why I want import / export. We sometimes work on a new 'wing' of a site, with custom software and other things behind it, and then find we can't easily import that wing's content into the main site). But I never get them confused with software. Ever. The bulk of my code, even, is in non-persistent objects (utilities, adapters, views, or just plain old python functions and objects), which makes refactoring and restructuring fiendishly easy. Since I seldom have to deal with anything akin to 'module aliases' any more, I feel more free to move code around and have had very few breakages and nary a broken object show up in the ZODB. I thought this uniformity of a development model was the Zope 3 message. Am I wrong? I know we were still trying to provide other messages at some point, including making things like 'sqlexpression' and full python statements available to through-the-web ZPT templates (and only to those, not to ViewPageTemplateFile type ones), but didn't think they were really taken or used seriously. I couldn't get them to work half the time anyways, so I never found use for them. I did find occasion to use a few TAL statements here and there in content space, but that's it. And that's only for a couple of deployments. Are others seriously developing with templates and scripts in 'content space' in Zope 3? Why? How? -- Jeff Shell _______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com