tables logicsheet? (was App Design Philosophy Rant)

[Allan Erskine <a....@cs.ucl.ac.uk>]

----- Original Message -----
From: "Donald Ball" <ba...@webslingerZ.com>

...

> some of those cons are bogus.
>
> > - Hard coded, redundant SQL-Statements spreaded all over your source
>
> 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 =

...

> then i just call
>
> <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...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.

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...

- Allan

----- Original Message -----
From: "Donald Ball" <ba...@webslingerZ.com>
To: "cocoon-users" <co...@xml.apache.org>
Sent: Wednesday, February 14, 2001 7:21 PM
Subject: Re: App Design Philosophy Rant


> On Wed, 14 Feb 2001, Markus Bernhardt wrote:
>
> > Lets look for an example at the esql-taglib.
> > Pro:
> > - Easy to use
> > - DB Connection Pooling
> > Con:
> > - Hard coded, redundant SQL-Statements spreaded all over your source
> > - No DB Result Pooling
> > - No abstraction of the datasource
> > - No cluster support
> > - No transaction support
> > - No lifecycle management
>
> some of those cons are bogus.
>
> > - Hard coded, redundant SQL-Statements spreaded all over your source
>
> 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 =
> <esql:parameter><xsl:apply-templates
> select="wzi:client-id/*"/></esql:parameter> order by name</esql:query>
>     <esql:results>
>       <contacts>
>         <esql:row-results>
>           <contact>
>             <id><esql:get-string column="id"/></id>
>             <name><esql:get-string column="name"/></name>
>             <phone><esql:get-string column="phone"/></phone>
>             <email><esql:get-string column="email"/></email>
>           </contact>
>         </esql:row-results>
>       </contacts>
>     </esql:results>
>   </esql:execute-query>
> </xsl:template>
>
> then i just call
>
> <wzi:get-contacts> wherever i want to in my xml pages.
>
> > - No abstraction of the datasource
>
> er... again, i think that depends on how you use xsp/esql. i can change
> the template for <wzi:get-contacts> to retrieve the data from whatever
> data source i choose.
>
> > - No transaction support
>
> see esql:autocommit
>
> in general, i think you point out some good reasons to take a good look at
> J2EE, but i don't agree with all of them.
>
> - donald
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>

Re: tables logicsheet? (was App Design Philosophy Rant)

[Ulrich Mayring <ul...@denic.de>]

Allan Erskine wrote:
> 
> A possible disadvantage may be the difficulty in building in enough
> flexibility into the tables logicsheet.

Yeah.. mucho work. Especially if you consider that tables are just the
start: there's forms, redirects etc.

> I'd be very interested in hearing what anyone thought of this, as I was
> seriously thinking of giving this approach a whirl...

Most of us already have something like this in place. But we can't agree
on a common ground yet.

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Re: tables logicsheet? (was App Design Philosophy Rant)

[Donald Ball <ba...@webslingerZ.com>]

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