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
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to