> > 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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, April 26, 2002 5:44 PM Subject: Re: Subproject Proposal - crossdb > on 4/26/02 2:30 PM, "Steve A. Olson" <[EMAIL PROTECTED]> 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: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>