Subject: Response to Article on ACS x Zope
From: <[email-masked]>
To: <[email-masked]>
Date: Thu, 15 Jun 2000 19:01:07 +1000

Chris McDonough ([email-masked]) responded to a message you
requested notification for in the OpenACS compared to other toolkits and
technologies bboard:

Subject:  Response to Article on ACS x Zope

To answer some of Albert's q's...

The ZPatterns stuff is the brainchild of Phillip Eby, a developer at Verio
(the
hosting provider).  It (among other things) is a mechanism to provide
medium-independent "propertysheet" support.  "Propertysheets" in Zope are
rectangular sets of typed data that can be attached to Zope objects
arbitrarily, and as such lend themselves very well to storage in an RDB
table.
And I think this was probably what Philip had in mind in providing Dynamic
Data
Objects.  Although to be honest, I might be totally wrong... I can't really
tell what the intent is now.  I've heard it's a good set of ideas, but
personally I'm stumped most of the time when I read his stuff because he
names
things very opaquely and seems to explain things in such a way that you *do*
need to community college C++ degree to begin to grasp it.  I think it's one
of
those projects that needs to gain some traction and obtain a critical mass
of
real-world examples in order to make its ultimate intent clear to mortals
like
me.  Until then, I can't speak much for it, although I do recommend you
continue looking at it.  (Maybe you can write some code using it that would
explain it to me!)

ZPatterns is not part of the Zope distribution.

I think Ben had in mind at least in his most recent posting an abstraction
layer that allowed RDB-savvy people to write SQL-like queries that would
automagically be translated into their equivalent optimized Oracle- or
Postgres-specific SQL dialect at runtime.  I don't think anybody in Zopeland
has the intent of writing such a beast.

You're probably right in assuming that the ZPatterns stuff is about as close
as
it gets to wanting to do something like that.  But Zope propertysheets are
generally by nature pretty small fixed sets of data (maybe 5 - 12 properties
per object).  You would need to declare some sort of table structure for a
particular object type, create the tables to store the propertysheet data
for
those kinds of objects, then do the right voodoo to tell the objects to
obtain
their properties out of SQL instead of out of the ZODB.  This could probably
be
abstracted in such a way that people don't need to write any SQL, but it
would
never approach the sort of complexity that I think Ben is talking about
because
it would probably practically necessitate an approach something along the
lines
of defining a table to hold propertysheet data for each different object
type.
If you wanted to do ad hoc queries against an existing set of data in
multiple
tables (ones that might require unions, outer joins, or insert selects)
would
need to be (just as painfully) manually constructed in the SQL dialect of
your
choice.  Personally, I'd probably try to keep it simple and create views on
existing tables that would let me operate as if I were doing so on a single
table.

Somehow I get the feeling that in this conversation we're all talking an
entirely different language than one another.  I assume that Ben's concerned
about complicated SQL abstraction between Oracle and Postgres because he
wants
to get rid of Oracle dependencies in ACS.  I think Albert's talking about
being
able to abstract the SQL out enough to not have to think about it at all
when
constructing an application.  I'm probably just plain not thinking about it
at
all.

I looked at Ben's sql-abstraction page... I don't know any tcl, but I think
I
get the gist.

It would seem to me to make sense to abstract out both 1) the access
mechanism
for querying and the 2) resultset that comes back from the query.  In Zope
we
do the first part by creating a "method" that contains the actual query
(which
can be as DB-specific or generic as you like), connecting it to a database
connection (a pool of database handles for a specific DB type).  You can
then
pass in arguments to the method that have counterpart template definitions
within the query itself (ala CUSTID = <dtml-sqlvar abc>), and the method
passes
the query in to the DB and obtains its results.

The second part (returning the results of the query to the caller) is
handled
in Zope by wrapping the resultset in a class instance that lets us process
those results generically.  It would probably be good to do something like
this
in ACS by defining a datatype that could hold arbitrary common elements that
could be processed in tcl code generically.

Though it's not a trivial engineering task, it seems like the biggest
problem
isn't implementing it, but encouraging people to use it.  From what I
understand there's a large body of existing code that does not use any sort
of
abstraction like this.  Convincing folks of the usefulness of writing
against
your interface instead of yanking the stuff right out of the tables in their
code is probably the hardest task.

-----------------

To post a response, come back to the bulletin board at

http://openacs.org/bboard/q-and-a.tcl?topic_id=8&topic=OpenACS%20compared%20
to%20other%20toolkits%20and%20technologies

-------------

If you are no longer interested in this thread, simply go to the
following URL and you will no longer get these notifications:

http://openacs.org/bboard/shut-up.tcl?row_id=1488768

-------------

Note:  this message was sent by a robot.