Re: SQLTags

["Steve A. Olson" <St...@ait-inc.com>]

>
> Bah. Throws the entire concept of MVC out the window.
>
> -jon

For a very complex application-- you are right-- the database layer should
be pushed to a lower level; I'll grant you that, however, the generator also
creates "base-table" classes for each underlying table  (independent of the
JSP tags) and can, thus, be used by a pure "Control" layer for any user
interface.

Additionally, for many less complex applications-- applications that mostly
provide a GUI front-end to a database or applications that are light on
"Control" logic-- the simplicity of using the generated tags, IMO, justifies
the sacrifice of MVC. And it is a significant improvement over JDBC snippets
or even DBTags (from jakarta-taglibs).  Also, the typical developer is lost
on the nuance of MVC but does understand a relational database table.

Finally, I believe, that with some careful thought-- and input from this
community-- that a design pattern (a state-machine, perhaps) could be
developed around a generic database and a generic user interface that could
make MVC more widely adopted.  ... Let me explain my thinking ...

We've started to experiment with a [crude] set of database events:
pre-insert, post-insert, pre-update, ... , pre-query, post-fetch,
post-query, etc.  These events provide developers with the ability to
customize the behavior of the base-table classes-- to add "Control" logic--
without cluttering up the page with snippets or touching the generated
classes.  For instance, the pre-insert event could be used to perform
validations, check permissions, provide auditing, set derived values, etc.
Additionally, the user interface could define "GUI" events like on-focus,
on-blur, on-load, etc.  We've also added the ability (at the JSP Tag layer)
to map request parameters to database columns and to process arrays of rows
(from the request object) and perform: inserts, updates, and deletes within
one tag-- one line of JSP code-- thus eliminating tons of "Model" code
normally needed to glue the "View" to the "Control".  This is possible
precisely because we let the events handle the "Control" for us; therefore,
we can use a convenient short-hand.

I think we could define a generic set of MVC events (embodied in an
Interface class) that could provide a rich MVC programming environment-- for
any user interface (JSP or SWING, for example) and any database.  This
generic user interface definition is needed so we can truly write the
"Control" logic once (and only once) and "glue" it, as efficiently and
concisely as possible, to any "supported" user interface ("Model/View").
The real issue isn't encapsulating the "Control" logic-- it's more about
managing the line between- and the code needed to integrate- the
"Model/View" and the "Control" layers.

MVC is a goal which, IMO, has been more a dream than a reality.  It was a
clear definition of SQL that gave rise to client/server-- the revolution of
the 1980s. Unfortunately, there has yet to be such a clear definition to
propel MVC to similar heights.  MVC is yet to be adopted by or even really
understood well by the average developer-- certainly not to the extent that
client/server (embodied by SQL) has.

I do think MVC is an essential concept for applications that must survive
over an extended period of time or that must provide service to many user
interfaces-- I just haven't seen the industry coalesce around any one
implementation yet.  OR ... perhaps ... I have simply missed the boat
completely  ... which is quite likely :^))  ...  Thanks for taking the time
to read this-- I do hope it was worth your time.

--Steve


----- Original Message -----
From: "Jon Scott Stevens" <jo...@latchkey.com>
To: <ge...@jakarta.apache.org>
Sent: Friday, April 26, 2002 5:44 PM
Subject: Re: Subproject Proposal - crossdb


> on 4/26/02 2:30 PM, "Steve A. Olson" <st...@ait-inc.com> wrote:
>
> > Regarding Generators ... not really O/R ... but we've had success with
> > SQLTags (www.sqltags.org) that uses a generator to produce a java class
and
> > JSP tag for each table defined by the JDBC metadata.  Each tag knows how
to
> > compose an insert, update, and delete statement; provides bean-style
access
> > to each column in the table; provides bean-style access to each parent
> > foreign and child key for the underlying table. The tags can be nested
to
> > provide master-detail relationships based on the foreign key name--
without
> > any SQL or JOINS.  SQLTags is currently very early in development, but
we
> > would welcome feedback from anyone who is interested.
> >
> > --Steve Olson
>
> Bah. Throws the entire concept of MVC out the window.
>
> -jon
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>