Return-Path: <balld@webslingerZ.com>
Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-users@xml.apache.org
Received: (qmail 61263 invoked from network); 16 Feb 2001 08:29:52 -0000
Received: from rdu162-231-084.nc.rr.com (HELO akira.webslingerZ.com)
 (postfix@24.162.231.84)
  by h31.sny.collab.net with SMTP; 16 Feb 2001 08:29:52 -0000
Received: by akira.webslingerZ.com (Postfix, from userid 501)
	id 48F091303F; Fri, 16 Feb 2001 03:30:58 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by akira.webslingerZ.com (Postfix) with ESMTP id 4655E60B2
	for <cocoon-users@xml.apache.org>; Fri, 16 Feb 2001 03:30:58 -0500 (EST)
Date: Fri, 16 Feb 2001 03:30:58 -0500 (EST)
From: Donald Ball <balld@webslingerZ.com>
X-Sender: <balld@rdu162-231-084>
To: <cocoon-users@xml.apache.org>
Subject: Re: tables logicsheet?  (was App Design Philosophy Rant)
In-Reply-To: <000201c097ac$57d72320$0179a8c0@spukny>
Message-ID: <Pine.LNX.4.30.0102160317120.1192-100000@rdu162-231-084>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

On Thu, 15 Feb 2001, Allan Erskine wrote:

> > depends on how you use esql. i write my own logicsheets which use esql in
> > turn, for instance:
> >
> > <xsl:template match="wzi:get-contacts">
> >   <esql:execute-query>
> >     <esql:query>select id,name,phone,email from contacts where client_id =
>
> > <wzi:get-contacts> wherever i want to in my xml pages.
>
> This looks like a very handy technique indeed....  What do you think the
> merits/problems would be with trying to generalise this approach...

the merits are that you get at least some level of implementation
independence. all that appears on your page is an element called
get-contacts. the element name is descriptive, more information can be
added using attributes or child elements, and the logic behind the
generation of the data can be changed at any time with no changes
necessary on the data pages. the drawback is that it resolving nested
configuration parameters can be tricky, especially for newbies.

perhaps
> try to write a logicsheet that allows things like
>
> <tables:define name="contact">
>     <rowspace>
>         <col>id</col>
>         <col>name</col>
>         <col>phone</col>
>         <col>email</col>
>     </rowspace>
>     <implementation type="sql" src="resource:/postgres-table-mapping.xsd">
>         <rowspace-mapping>
>             <map from="id" to="ID">
>             ...
>         </rowspace-mapping>
>     </implementation>
> </tables:define>
>
> Then users could add <tables:get-table name="contact"/> tags throughout
> their code, with the possible advantage of knowing the tables are being
> generated in a consistent way.  You can imagine corresponding form or
> validator logicsheets that could construct say form instances based on
> tables.

i think you would enjoy checking out the castor project
(http://castor.exolab.org/). personally, i find this way of structuring a
sql to xml mapping to be difficult, plus it sort of simply treats the sql
database as a simple storage mechanism, which doesn't exploit the power of
SQL databases to sift through and combine large datasets with great
rapidity. i'm more interested in future evolution of things like xql.
we're making do pretty well with a mix of sql and xpath queries right now,
but within a few years i expect that to have changed.

> A possible disadvantage may be the difficulty in building in enough
> flexibility into the tables logicsheet.
>
> I'd be very interested in hearing what anyone thought of this, as I was
> seriously thinking of giving this approach a whirl...

it would be interesting to see what you come up with if you decided to
play around with this.

- donald