On 2/10/06, 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.
How? How "first class"? Does first class mean "supports SQLite level features"? "MySQL"? Then what happens when you have people needing to use real commercial databases who find a serious lack of support for the features that they want or need? How would you tie that in? Without offending those who just want to use SQLlite to store comments? Would it be all manual SQL statements? Would the be through an O-R layer? What about those (like my company) who have customers on RDBMS and other storage systems that have complex data handling and security requirements that go far beyond most O-R mappers (especially those that appeal to those just wanting a web page to have comments?) Would it be a pain in the ass to integrate a completely custom and different data management layer in? Would it be easy? "extra effort?" This smells like Zope 2 development, but without the ZODB. Just a bunch of little templates and scripts and SQL statements on the file system. The best day in many of Bottlerocket's Zope 2 era RDBMS applications was when we moved them away from both models. Being neither an O-R mapper, nor just full of endless similar SQL statements for basic CRUD stuff (but still using them, as methods on Python classes usually, for custom queries). Personally, I think that a Data Mapper layer that used zope.schema would be very effective. This is essentially what we built in Zope 2, using Formulator. Formulator ensured the data was in a clean / common format and satisfied any constraints, and a very simple layer generated SQL Methods on the fly based on the filtered down data that came in / out. If we migrate any of those applications to Zope 3 and keep the same data model, I easily see us doing it using zope.schema and doing directlyProvides or something like that on what is produced. It's not a situation that works for everyone. But it's one that works for us and is adaptive to different storage solutions. Our 'enterprise' level data management works on a similar level, but with a lot more transformations going on as data flows to / from its sources (and that data management framework itself has no dependencies on Zope, but a simple Gateway allows us to use it with Zope 2 while letting Zope 2 acquire the page templates, authenticated user, etc). Anyways, it's a scenario that I like because the data in these situations is more important to me than whether it looks sorta-like a Python object, yet the boring and repetitive operations are still taken care of. 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. If it doesn't kick and scream, we just need clear documentation that's neither too short nor too wordy about what to do... "I just installed cElementTree and have an XML document that I've turned into a Python object. How can I show that in Zope?" > However, I expect ZODB to continue to be the dominant platform for > writing Zope applications, because ZODB is quite productive for writing > abstract applications. ZODB is also very productive in Zope 3 for writing concrete applications. Now that our ZODB databases aren't polluted with a mixture of business objects as well as scripts, icons, sql, templates, etc, the ZODB is a joy to work with. It's very productive for writing NEW applications. I see these other tutorials for every O-R backed database and I'm thinking - "you're only creating a two column table to do a to-do list... why do you even have an RDBMS? you're not generating SQL directly and yay - it turns the todos into Python booleans and strings! Well, uh, again, why even have an RDBMS?" An application that I just completed would have actually been very hard with an RDBMS (especially as data requirements changed - 'can we have that field be in the leg?'). It would have taken me a lot longer to implement if I had to keep switching my mind back and forth between SQL and Python. THIS IS A HUGE ADVANTAGE! Why do we act like we're embarrassed by the ZODB? With zc.catalog, schoolbell.relationships, and vocabularies, I was able to make widgets that assign and remove related things from distinct locations in the system and never once had to think about a lookup table, or where to store the relationship widget information between pages if there were errors. Not once. And our customer? Very happy with the application. They don't care how the data is stored. They just care about the data. Oh yeah, and we have easy undo. Delete something? The resulting page now has a message with a link - "Deleted foobar (undo delete?)". Awesome. Why would we want to downplay this now that working with data and the ZODB seems so easy? With BrowserView (and FTP views too) as objects on the file system, divided into smaller units of work, our ZODB doesn't feel polluted or strange or mystical in any way. The number of persistent objects we have is usually quite small, their schema well defined. These are not just abstract applications. In fact, they're far less abstract and mysterious than anything ZODB based that I've written for Zope 2 over the last few years where I know far less about what's being stored, let alone how to associate a far-flung view with it. > 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. But Zope 3 has, so far, tried to pride itself on being a more limited diet (to run with your metaphor). Zope 2 is the feast of many kinds of food. ZClasses, ZSQL Methods, DTML Methods, Python Scripts, Properties (we did quite an impressive simple product using nothing more than DTML Documents and properties), file system based products, a sprawling array of CMF / Plone derived options (from web and file system skins to things like Archetypes)... No easy way to tie many of them together. And this proposal reminds me of that. In Zope 2, and all the way back to Principia, it was smack flippin easy to make a dynamic web page and a couple of supporting scripts / sql methods / whatever. Those next steps were harder. Knowing a good design to follow was harder, even if one wanted to stay in the through-the-web environment. I think that, so far, Zope 3 has made it pretty obvious that you can do a few dynamic things in the through-the-web side (and having templates in content space has been beneficial for one of our customers, even if they rarely have to use them now). But to really get things done, there's one way of doing it and that is pretty regular Python development. As I wrote earlier today - comparing what I considered to be pretty well factored Zope 2 based code (in a Python product, using our e-commerce framework and an in-house component-architecture-light style support system) that I wrote about a year and a half ago against Zope 3 code I wrote in the last couple of weeks, I was amazed. The Zope 3 based Python code was easier on the eyes, easier on the brain. They were both doing similar things. But somehow, it was just easier to keep the Zope 3 backed code simple. It was simple because refactoring is easier. Because it's so much more like regular Python. It's not some magic file that suddenly gets executed. It's a view that gets attached to a certain object because I said it could. It's a function that I can call because I can import it and not have to worry about "can I import this function in a Python Script?". It's a query that I can execute because I have the utilities needed to execute the query because I explicitly called them, not because they magically and wonderfully got bound. To me, this is heaven. I feel like I have control for the first time in a long time. I no longer run into surprises. My tabs aren't going to suddenly render funny because I dropped a folder named 'target' into the path. And when I start a new application up next week, it will be grounded in all of the exact same principals that I've been using since last summer. No wondering if "well, it's going to be a simple application, perhaps we could just drop in a couple of scripts and template and call it good. Or.. well, maybe it will grow, should we not do it that way?" I think that people are less likely to stay for the feast if there's "here's how to do things with an RDBMS" and "here's the full zope.app framework which works great with the ZODB and containment and containers and annotations and this and that" and there's a big divide between the two yet they're both presented as options. I stand by my desire for there to be a stripped down Zope that doesn't even care about RDBMS's. It's just about publishing things on the web. Maybe it provides transactions in the way that Bobo's always done. But the other steps are up to... well, whomever wants to take them on. I'd be happy to use something like that when I don't need all of zope.app. I'd hate to see all of zope.app sitting there, however, and wondering "if I use this... does that mean I'll be needing to support this, this, this, this, and this?" and "if I want to use that, can I use that with my XML database?" and feeling frustrated when all is said and done. I'd love to have that simple tool I used back in spring of '97 (Bobo and DTML, but not BoboPOS - which nowadays would be zope.publisher and zope.pagetemplate (tal/tales) and not ZODB). But I would not want to have some bigger weirder tool that gave me too many options about how to start something, and then how to grow it. I imagine that a Zope 3 Bobo Based app could / should be able to grow into a full Zope 3 app without too much effort. I can't imagine a bunch of templates and sql scripts on the file system turning into an advanced application with the same minimum of effort. It comes back to that frustration I have with some of the ZCML directives. "Alright, I used browser:page. But now, I want to call the template myself and provide an interface... how do I make this grow up? What did browser:page do for me that I now have to do myself?" (and my personal favorite - "why can't I traverse this? why did traverse work in TALES but not the URL? why did it happen the other way around that other time?".. I still dont' understand all of the traversal options. How's this 'newbie' going to understand why sometimes he can traverse and sometimes he can't?) I could see the same scenario: "well, I had this page template on the file system and it just did its work. now I want to use it directly for the front page of my project manager tool. How can I associate it? What did this system do automatically before that I now have to do for myself?" _______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com