velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Freeman" <>
Subject RE: Velocity + Database [long]
Date Thu, 07 Aug 2003 18:42:32 GMT
> > Current MVC implementations require that the objects referred to above
> > always reside within an application, without having the
> flexibility to allow
> > the objects to reside in the database.  IMHO, this is not a
> good thing . . .
> > its a bias toward a particular technology.
> I'm not sure what this means--I store both objects and plain old data in
> the database (well, that's I'm using for persistence right now, anyway.)
> What do you mean by having objects reside in the database?

Lets use velocity and struts for example.  If you want to define/use the
notion of an object you must create a Java class file that is compiled and
then loaded by the JVM under which Velocity or Struts is running.  So the
notion of an object from the VTL/JSP stand point always means: Look up a
Java object reference and communicate with it (execute Java methods and read
Java properties from that Java object).

I am saying that for MVC implementations to be more useful from an
enterprise development standpoint would be to extend the notion of an
"object" to allow references to SQL templates that would make the
appropriate calls on the database.  These SQL templates would be "objects"
in and of themselves.  I'll just make a simple syntax as an example.  I am
doing this off the cuff so it might not look smooth, but it demonstrates the

Perhaps the name of the script file is the class of the object.

	SELECT name
	  FROM users
       WHERE unique_user = ${unique_user}

		(name, age, date)
		(${username}, ${age}, ${date})

Then in the pages you could reference the property via: ${User.username}
And to add a user to the database a page designer could call:
${User.addUser('Fred', '13)}

Again, this is off the cuff so I am sure there are a ton of holes in it, but
the idea is to get the SQL outside of the Java realm.  A SQL programmer
could easily modify that template and never look at Java code.  A page
designer can easily manipulate that database but only via calls through the
.sql template.

> > To satisfy this, why can't the "adaptor" be an SQL "object"
> that interfaces
> > with the underlying entity as opposed to a Java object that has
> embedded SQL
> > that interfaces with the underlying entity?  Then MVC is not locked into
> > Java objects only.
> I don't know what you mean by being "locked into java objects only" (MVC
> is a way, not a platform) but... to me it sounds like this is a semantic
> point... So the SQL object is "really" a java object with SQL that talks
> to an SQL database--what's the difference?

Right, MVC is a "way", but I am referring to the _implementation_ -- not the
MVC paradigm.  No the SQL object is a template that is read by a canned Java
class that executes what it reads out of the template.  The Java class would
never change.  It is installed with the struts/velocity/whatever server and
simply reads the proper template, swaps out variable names appropriately and
executes the SQL.  It knows nothing about the layout of the database or the
SQL.  It reads, executes, dies.

> I need to see an example of what you mean. So far it just sounds like
> you want to be able to embed SQL stuff on a page. But the point of MVC
> is to avoid that.
> Obviously I'm missing what you're saying; sorry :(

Not in the page, in a separate template that objectifies the SQL from the
page designers view.

Does that help?


View raw message