You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Aaron Freeman <aa...@layerz.com> on 2003/07/26 20:11:18 UTC
Velocity + Database
Are there any Velocity tool sets that allow you to write your database SQL
inside your .vm templates instead of having to bury the SQL code inside of
servlets? I am thinking of something similar to Coldfusion's ability to
have the SQL inside of <CFQUERY></CFQUERY> tags, and then you can reference
the data dynamically without even needing to write your own servlet.
If not this would be an extremely cool servlet/tool to add to Velocity's
tool set.
Aaron Freeman
Layer-Z, Inc.
Phone: (316) 729-9968
Fax: (215) 895-9813
aaron@layerz.com
http://www.layerz.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Velocity + Database
Posted by Ted Husted <hu...@apache.org>.
This is getting way off topic, and I apologize for that, but I was just
curious as to whether anyone has talked about porting Velosurf to .NET?
-- so that it could be used with the .NET versions of Velocity and
Maverick (for example).
There was some work in this regarding with Hibernate, but the developers
seemed to get bogged down in the complexity of the task.
-Ted.
Claude Brisson wrote:
> Interesting thread, indeed.
>
> Hibernate is for sure a great piece of work, I almost choosed to use it before I finally choose to develop velosurf.
>
> The main reasin is I did not want the inherant complexity brought up by the persistence. Today confusers are so speed that making
> direct accesses to the database is not so heavy, also considering you can do a lot with some dummy hash caching at clever places.
> Also, Velosurf is more lightweight and meant to be use with the Velocity view layer. But I'm sure there's still some ideas I could
> borrow from Hibernate.
>
> Aaron, bad boy ;-), I suspect you did not yet check out Velosurf, it has many of the features you are requesting :
> - no need to recompile java on any database change
> - you can define objects, properties and methods in the xml file that gathers sql (except that the terminology is
> "entities,attributes & actions"), and then choose to inherit them with your own java classes
>
> If you still think Velosurf is not approriate in regard of your needs, please let me know why
>
> @+
>
> CloD
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Ted Husted,
Junit in Action - <http://www.manning.com/massol/>,
Struts in Action - <http://husted.com/struts/book.html>,
JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Velocity + Database
Posted by Ted Husted <hu...@apache.org>.
This is getting way off topic, and I apologize for that, but I was just
curious as to whether anyone has talked about porting Velosurf to .NET?
-- so that it could be used with the .NET versions of Velocity and
Maverick (for example).
There was some work in this regarding with Hibernate, but the developers
seemed to get bogged down in the complexity of the task.
-Ted.
Claude Brisson wrote:
> Interesting thread, indeed.
>
> Hibernate is for sure a great piece of work, I almost choosed to use it before I finally choose to develop velosurf.
>
> The main reasin is I did not want the inherant complexity brought up by the persistence. Today confusers are so speed that making
> direct accesses to the database is not so heavy, also considering you can do a lot with some dummy hash caching at clever places.
> Also, Velosurf is more lightweight and meant to be use with the Velocity view layer. But I'm sure there's still some ideas I could
> borrow from Hibernate.
>
> Aaron, bad boy ;-), I suspect you did not yet check out Velosurf, it has many of the features you are requesting :
> - no need to recompile java on any database change
> - you can define objects, properties and methods in the xml file that gathers sql (except that the terminology is
> "entities,attributes & actions"), and then choose to inherit them with your own java classes
>
> If you still think Velosurf is not approriate in regard of your needs, please let me know why
>
> @+
>
> CloD
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Ted Husted,
Junit in Action - <http://www.manning.com/massol/>,
Struts in Action - <http://husted.com/struts/book.html>,
JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
Re: Velocity + Database
Posted by Nathan Bubna <na...@esha.com>.
Aaron Freeman said:
...
> I think the primary reason I didn't use it was because I was intimidated by
> the toolbox.xml file.
sorry to hear that, but now that you've had that experience, have you got any
suggestions for ways to make the Velocity Tools documentation/examples less
intimidating? intimidating newbies is definitely not a goal of the
project(s). :)
> I was (am) so new to Velocity that I didn't understand
> how all the pieces fit together. I know now that the Tools are no big deal
> but at the time it was confusing to me (not because of your implementation
> but because I was trying to digest what had to be done very quickly and
> didn't know the lay of the land [at the time I had never even heard of the
> "toolbox.xml"]). It took me a couple of days with VelocityView to learn that
> they are the method to extend Velocity (although the name is self
> explanatory, the layout wasn't).
...
just to quibble over semantics a bit... i would say that the toolbox/tools is
not a way to extend Velocity, but a way to automatically populate the velocity
context (and a simple, flexible, and powerful way at that!). ;)
>
> Ok, ok, I admit it ... I'm a cry baby ... I want to be spoon-fed the info!
>
so maybe we haven't spoon fed you well. if you really believe in spoon
feeding, why not help us spoon feed others once you get past the "cry baby"
stage? ;)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Velocity + Database
Posted by Nathan Bubna <na...@esha.com>.
Aaron Freeman said:
...
> I think the primary reason I didn't use it was because I was intimidated by
> the toolbox.xml file.
sorry to hear that, but now that you've had that experience, have you got any
suggestions for ways to make the Velocity Tools documentation/examples less
intimidating? intimidating newbies is definitely not a goal of the
project(s). :)
> I was (am) so new to Velocity that I didn't understand
> how all the pieces fit together. I know now that the Tools are no big deal
> but at the time it was confusing to me (not because of your implementation
> but because I was trying to digest what had to be done very quickly and
> didn't know the lay of the land [at the time I had never even heard of the
> "toolbox.xml"]). It took me a couple of days with VelocityView to learn that
> they are the method to extend Velocity (although the name is self
> explanatory, the layout wasn't).
...
just to quibble over semantics a bit... i would say that the toolbox/tools is
not a way to extend Velocity, but a way to automatically populate the velocity
context (and a simple, flexible, and powerful way at that!). ;)
>
> Ok, ok, I admit it ... I'm a cry baby ... I want to be spoon-fed the info!
>
so maybe we haven't spoon fed you well. if you really believe in spoon
feeding, why not help us spoon feed others once you get past the "cry baby"
stage? ;)
Nathan Bubna
nathan@esha.com
Re: Velocity + Database
Posted by Claude Brisson <cl...@savoirweb.com>.
(sorry for the delay...)
Aaron wrote :
> I didn't notice that you could embed SQL using velosurf. So I could just do
> a #parse(filewithsql.sql) to include it? That would allow my DBAs to work
> with the SQL, the designers to work with the pages, and my Java programmers
> to keep cutting code regardless the structure of the DB?
You can't embed sql with #parse, and it's an implementation choice ! :-)
This would tie the template containing the #parse directive with the sql file.
Instead, you gather sql code in the velosurf.xml file. And DBAs, designers and
java programmers can work on separate sections.
> IMHO it would help your cause a little if you had some _very_ simple
> examples of using Velosurf to:
>
> a) pull a single value out of the database and display it (a Hello World if
> you will so we can get a super quick notion of your syntax)
Assuming you have a table named 'message' which contains (id=1, text='Hello World'),
the Hello World display app would be :
$db.messages.fetch(1).text
Or, to be more explicit :
#set( $hello = $db.messages.fetch(1) )
$hello.text
> b) pull multiple rows of a single column out and loop through them simply
> displaying them on the screen in sequential order
#foreach($message in $db.messages)
$message.text
#end
> c) show a single insert
Assuming that $values is an empty map and that the 'id' column is autoincremental :
#set( $values.text = 'How do you do ?' )
#set( $success = $db.messages.insert($values) )
#if ($success)
New row inserted : id = $db.messages.lastInsertID
#else
Error : $db.error
#end
Hope that'll help.
I'll put those examples in the doc.
> Ok, ok, I admit it ... I'm a cry baby ... I want to be spoon-fed the info!
And I admit that Velosurf documentation still needs some enhancements... Would you or anyone else want to help ?
CloD
RE: Velocity + Database
Posted by Aaron Freeman <aa...@layerz.com>.
> Aaron, bad boy ;-), I suspect you did not yet check out Velosurf,
> it has many of the features you are requesting :
> - no need to recompile java on any database change
> - you can define objects, properties and methods in the xml file
> that gathers sql (except that the terminology is
> "entities,attributes & actions"), and then choose to inherit them
> with your own java classes
>
> If you still think Velosurf is not approriate in regard of your
> needs, please let me know why
:) Well, I actually did go there and I downloaded the library, but I was far
enough down the road with my own template parser and so new to Velocity that
I chose to just finish my parser off.
I didn't notice that you could embed SQL using velosurf. So I could just do
a #parse(filewithsql.sql) to include it? That would allow my DBAs to work
with the SQL, the designers to work with the pages, and my Java programmers
to keep cutting code regardless the structure of the DB?
IMHO it would help your cause a little if you had some _very_ simple
examples of using Velosurf to:
a) pull a single value out of the database and display it (a Hello World if
you will so we can get a super quick notion of your syntax)
b) pull multiple rows of a single column out and loop through them simply
displaying them on the screen in sequential order
c) show a single insert
I think this would entice more users to jump right in because the "very
simple example" on your page is not so simple if you are new to Velocity
itself (which I am). The examples should be like 5 lines of code or less if
possible, just to get a quick feel for the syntax. This way even if you are
new to velocity the whole thing will still be obvious, and it will be
apparent how to do simple things.
I think the primary reason I didn't use it was because I was intimidated by
the toolbox.xml file. I was (am) so new to Velocity that I didn't understand
how all the pieces fit together. I know now that the Tools are no big deal
but at the time it was confusing to me (not because of your implementation
but because I was trying to digest what had to be done very quickly and
didn't know the lay of the land [at the time I had never even heard of the
"toolbox.xml"]). It took me a couple of days with VelocityView to learn that
they are the method to extend Velocity (although the name is self
explanatory, the layout wasn't).
Ok, ok, I admit it ... I'm a cry baby ... I want to be spoon-fed the info!
Just my $0.02.
-a
RE: Velocity + Database
Posted by Aaron Freeman <aa...@layerz.com>.
> Aaron, bad boy ;-), I suspect you did not yet check out Velosurf,
> it has many of the features you are requesting :
> - no need to recompile java on any database change
> - you can define objects, properties and methods in the xml file
> that gathers sql (except that the terminology is
> "entities,attributes & actions"), and then choose to inherit them
> with your own java classes
>
> If you still think Velosurf is not approriate in regard of your
> needs, please let me know why
:) Well, I actually did go there and I downloaded the library, but I was far
enough down the road with my own template parser and so new to Velocity that
I chose to just finish my parser off.
I didn't notice that you could embed SQL using velosurf. So I could just do
a #parse(filewithsql.sql) to include it? That would allow my DBAs to work
with the SQL, the designers to work with the pages, and my Java programmers
to keep cutting code regardless the structure of the DB?
IMHO it would help your cause a little if you had some _very_ simple
examples of using Velosurf to:
a) pull a single value out of the database and display it (a Hello World if
you will so we can get a super quick notion of your syntax)
b) pull multiple rows of a single column out and loop through them simply
displaying them on the screen in sequential order
c) show a single insert
I think this would entice more users to jump right in because the "very
simple example" on your page is not so simple if you are new to Velocity
itself (which I am). The examples should be like 5 lines of code or less if
possible, just to get a quick feel for the syntax. This way even if you are
new to velocity the whole thing will still be obvious, and it will be
apparent how to do simple things.
I think the primary reason I didn't use it was because I was intimidated by
the toolbox.xml file. I was (am) so new to Velocity that I didn't understand
how all the pieces fit together. I know now that the Tools are no big deal
but at the time it was confusing to me (not because of your implementation
but because I was trying to digest what had to be done very quickly and
didn't know the lay of the land [at the time I had never even heard of the
"toolbox.xml"]). It took me a couple of days with VelocityView to learn that
they are the method to extend Velocity (although the name is self
explanatory, the layout wasn't).
Ok, ok, I admit it ... I'm a cry baby ... I want to be spoon-fed the info!
Just my $0.02.
-a
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Velocity + Database
Posted by Claude Brisson <cl...@savoirweb.com>.
Interesting thread, indeed.
Hibernate is for sure a great piece of work, I almost choosed to use it before I finally choose to develop velosurf.
The main reasin is I did not want the inherant complexity brought up by the persistence. Today confusers are so speed that making
direct accesses to the database is not so heavy, also considering you can do a lot with some dummy hash caching at clever places.
Also, Velosurf is more lightweight and meant to be use with the Velocity view layer. But I'm sure there's still some ideas I could
borrow from Hibernate.
Aaron, bad boy ;-), I suspect you did not yet check out Velosurf, it has many of the features you are requesting :
- no need to recompile java on any database change
- you can define objects, properties and methods in the xml file that gathers sql (except that the terminology is
"entities,attributes & actions"), and then choose to inherit them with your own java classes
If you still think Velosurf is not approriate in regard of your needs, please let me know why
@+
CloD
Re: Velocity + Database
Posted by Claude Brisson <cl...@savoirweb.com>.
Interesting thread, indeed.
Hibernate is for sure a great piece of work, I almost choosed to use it before I finally choose to develop velosurf.
The main reasin is I did not want the inherant complexity brought up by the persistence. Today confusers are so speed that making
direct accesses to the database is not so heavy, also considering you can do a lot with some dummy hash caching at clever places.
Also, Velosurf is more lightweight and meant to be use with the Velocity view layer. But I'm sure there's still some ideas I could
borrow from Hibernate.
Aaron, bad boy ;-), I suspect you did not yet check out Velosurf, it has many of the features you are requesting :
- no need to recompile java on any database change
- you can define objects, properties and methods in the xml file that gathers sql (except that the terminology is
"entities,attributes & actions"), and then choose to inherit them with your own java classes
If you still think Velosurf is not approriate in regard of your needs, please let me know why
@+
CloD
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Velocity + Database
Posted by Ted Husted <hu...@apache.org>.
Charles N. Harvey III wrote:
> Would you mind letting me know where you found such a system?
> I am using OJB and I have been looking at Torque, is that what you
> are using to do all this code and database generation? If not, I would
> love to find out (if it is publicly available).
Hibernate is another good example. The mappings between the Application
Model objects and the database tables are expressed in XML. Internally,
the Java code just asks Hibernate for such and such an object; there are
no references to SQL at all. Externally, you can make very significant
changes in the way the objects are stored in the database without making
any changes to the Java code. The XML needs to be parsed again, but the
Java code does not need to be recompiled.
I'd love to be able to do the same sort of thing between transfer
objects and the Application Model. From the page's POV, most input and
output queries should appear as a flat object, or a flat object with a
few shallow lists.
Of course, you can pass the Application Model objects directly to the
page, but, IMHO, that creates the same sort of binding we're trying to
avoid with the database system. It could be quite useful to declare in
XML how to convert a rich Application Model object to a shallow transfer
object in XML, just as many systems now let us declare how to store a
rich Application Model object to a relational database.
-Ted.
--
Ted Husted,
Junit in Action - <http://www.manning.com/massol/>,
Struts in Action - <http://husted.com/struts/book.html>,
JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
RE: Velocity + Database [long]
Posted by Dave Newton <da...@solaraccess.com>.
On Thu, 2003-08-07 at 14:42, Charles N. Harvey III wrote:
> > From: Dave Newton [mailto:dave@solaraccess.com]
> > I'm currently using a system that uses an XML file to define our
> > database tables. The database build and java class generation is
> > automagic. Unless the model requires non-generic handling of new fields,
> > tables, etc. I rarely have to code anything.
>
> Would you mind letting me know where you found such a system?
> I am using OJB and I have been looking at Torque, is that what you
> are using to do all this code and database generation? If not, I would
> love to find out (if it is publicly available).
we're using Torque with some modified template files and some minor
utilities in Jython that aren't any big deal. I'd like (which may exist
already) a nice IDE for designing the database tables/keys/etc but other
than that everything has been very pleasant so far.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Velocity + Database
Posted by Ted Husted <hu...@apache.org>.
Charles N. Harvey III wrote:
> Would you mind letting me know where you found such a system?
> I am using OJB and I have been looking at Torque, is that what you
> are using to do all this code and database generation? If not, I would
> love to find out (if it is publicly available).
Hibernate is another good example. The mappings between the Application
Model objects and the database tables are expressed in XML. Internally,
the Java code just asks Hibernate for such and such an object; there are
no references to SQL at all. Externally, you can make very significant
changes in the way the objects are stored in the database without making
any changes to the Java code. The XML needs to be parsed again, but the
Java code does not need to be recompiled.
I'd love to be able to do the same sort of thing between transfer
objects and the Application Model. From the page's POV, most input and
output queries should appear as a flat object, or a flat object with a
few shallow lists.
Of course, you can pass the Application Model objects directly to the
page, but, IMHO, that creates the same sort of binding we're trying to
avoid with the database system. It could be quite useful to declare in
XML how to convert a rich Application Model object to a shallow transfer
object in XML, just as many systems now let us declare how to store a
rich Application Model object to a relational database.
-Ted.
--
Ted Husted,
Junit in Action - <http://www.manning.com/massol/>,
Struts in Action - <http://husted.com/struts/book.html>,
JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: Velocity + Database [long]
Posted by Dave Newton <da...@solaraccess.com>.
On Thu, 2003-08-07 at 14:42, Charles N. Harvey III wrote:
> > From: Dave Newton [mailto:dave@solaraccess.com]
> > I'm currently using a system that uses an XML file to define our
> > database tables. The database build and java class generation is
> > automagic. Unless the model requires non-generic handling of new fields,
> > tables, etc. I rarely have to code anything.
>
> Would you mind letting me know where you found such a system?
> I am using OJB and I have been looking at Torque, is that what you
> are using to do all this code and database generation? If not, I would
> love to find out (if it is publicly available).
we're using Torque with some modified template files and some minor
utilities in Jython that aren't any big deal. I'd like (which may exist
already) a nice IDE for designing the database tables/keys/etc but other
than that everything has been very pleasant so far.
Dave
RE: Velocity + Database [long]
Posted by "Charles N. Harvey III" <ch...@alloy.com>.
> -----Original Message-----
> From: Dave Newton [mailto:dave@solaraccess.com]
>
> I'm currently using a system that uses an XML file to define our
> database tables. The database build and java class generation is
> automagic. Unless the model requires non-generic handling of new fields,
> tables, etc. I rarely have to code anything.
Would you mind letting me know where you found such a system?
I am using OJB and I have been looking at Torque, is that what you
are using to do all this code and database generation? If not, I would
love to find out (if it is publicly available).
Charlie
RE: Velocity + Database [long]
Posted by Dave Newton <da...@solaraccess.com>.
On Thu, 2003-08-07 at 16:59, Aaron Freeman wrote:
> > So, more or less, you want to be able to execute SQL by defining SQL
> > statements attached to methods in an XML file?
>
> Yes, I think that sums it up succinctly.
>
> > I don't recall the classname now but there's something that will take a
> > result set and wrap it up providing named accessors to fields
> > (beanutil's RowSetDynaClass?)... Seems like tweaking some of that with
> > an XML parser for your config file and a java class generator might be
> > enough to solve the problem in a relatively easy way.
>
> In this scenario is the generator used on the fly or only at compile time?
Well, I'm not sure that it really matters. Obviously compile-time would
be easier 'cuz you could just translate straight from the XML into .java
files, but you could do it dynamically if you wanted I reckon.
Also, just to be pathological, what if you switch to a system where
something that doesn't use SQL is being used to persist data? While
creating ad-hoc queries using the object model should still work the SQL
bits wouldn't unless translated somehow.
I think allowing unfettered access to a backing store breaks MVC on a
fairly fundamental level but I could be over-reacting :)
Dave
RE: Velocity + Database [long]
Posted by Dave Newton <da...@solaraccess.com>.
On Thu, 2003-08-07 at 16:59, Aaron Freeman wrote:
> > So, more or less, you want to be able to execute SQL by defining SQL
> > statements attached to methods in an XML file?
>
> Yes, I think that sums it up succinctly.
>
> > I don't recall the classname now but there's something that will take a
> > result set and wrap it up providing named accessors to fields
> > (beanutil's RowSetDynaClass?)... Seems like tweaking some of that with
> > an XML parser for your config file and a java class generator might be
> > enough to solve the problem in a relatively easy way.
>
> In this scenario is the generator used on the fly or only at compile time?
Well, I'm not sure that it really matters. Obviously compile-time would
be easier 'cuz you could just translate straight from the XML into .java
files, but you could do it dynamically if you wanted I reckon.
Also, just to be pathological, what if you switch to a system where
something that doesn't use SQL is being used to persist data? While
creating ad-hoc queries using the object model should still work the SQL
bits wouldn't unless translated somehow.
I think allowing unfettered access to a backing store breaks MVC on a
fairly fundamental level but I could be over-reacting :)
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: Velocity + Database [long]
Posted by Aaron Freeman <aa...@layerz.com>.
> On Thu, 2003-08-07 at 14:42, Aaron Freeman wrote:
> > 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.
>
> I see what you're saying. Is this any different (other than syntactic
> sugar) than using something like a JSP SQL query tag of whichever
> nature? (Other than the obvious difference of where the SQL statements
> are defined.)
Probably, let me go look that up!
> > 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.
>
> So, more or less, you want to be able to execute SQL by defining SQL
> statements attached to methods in an XML file?
Yes, I think that sums it up succinctly.
> I don't recall the classname now but there's something that will take a
> result set and wrap it up providing named accessors to fields
> (beanutil's RowSetDynaClass?)... Seems like tweaking some of that with
> an XML parser for your config file and a java class generator might be
> enough to solve the problem in a relatively easy way.
In this scenario is the generator used on the fly or only at compile time?
-a
RE: Velocity + Database [long]
Posted by Aaron Freeman <aa...@layerz.com>.
> On Thu, 2003-08-07 at 14:42, Aaron Freeman wrote:
> > 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.
>
> I see what you're saying. Is this any different (other than syntactic
> sugar) than using something like a JSP SQL query tag of whichever
> nature? (Other than the obvious difference of where the SQL statements
> are defined.)
Probably, let me go look that up!
> > 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.
>
> So, more or less, you want to be able to execute SQL by defining SQL
> statements attached to methods in an XML file?
Yes, I think that sums it up succinctly.
> I don't recall the classname now but there's something that will take a
> result set and wrap it up providing named accessors to fields
> (beanutil's RowSetDynaClass?)... Seems like tweaking some of that with
> an XML parser for your config file and a java class generator might be
> enough to solve the problem in a relatively easy way.
In this scenario is the generator used on the fly or only at compile time?
-a
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: Velocity + Database [long]
Posted by Dave Newton <da...@solaraccess.com>.
On Thu, 2003-08-07 at 14:42, Aaron Freeman wrote:
> 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.
I see what you're saying. Is this any different (other than syntactic
sugar) than using something like a JSP SQL query tag of whichever
nature? (Other than the obvious difference of where the SQL statements
are defined.)
> 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.
So, more or less, you want to be able to execute SQL by defining SQL
statements attached to methods in an XML file?
I don't recall the classname now but there's something that will take a
result set and wrap it up providing named accessors to fields
(beanutil's RowSetDynaClass?)... Seems like tweaking some of that with
an XML parser for your config file and a java class generator might be
enough to solve the problem in a relatively easy way.
> Does that help?
Yep, thanks :)
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: Velocity + Database [long]
Posted by Dave Newton <da...@solaraccess.com>.
On Thu, 2003-08-07 at 14:42, Aaron Freeman wrote:
> 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.
I see what you're saying. Is this any different (other than syntactic
sugar) than using something like a JSP SQL query tag of whichever
nature? (Other than the obvious difference of where the SQL statements
are defined.)
> 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.
So, more or less, you want to be able to execute SQL by defining SQL
statements attached to methods in an XML file?
I don't recall the classname now but there's something that will take a
result set and wrap it up providing named accessors to fields
(beanutil's RowSetDynaClass?)... Seems like tweaking some of that with
an XML parser for your config file and a java class generator might be
enough to solve the problem in a relatively easy way.
> Does that help?
Yep, thanks :)
Dave
RE: Velocity + Database [long]
Posted by Aaron Freeman <aa...@layerz.com>.
> > 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
point.
Perhaps the name of the script file is the class of the object.
User.sql
--------------------------
<property>
<name>username</name>
SELECT name
FROM users
WHERE unique_user = ${unique_user}
</property>
<method>
<name>addUser</name>
INSERT INTO users
(name, age, date)
WHERE
(${username}, ${age}, ${date})
</method>
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?
-a
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: Velocity + Database [long]
Posted by "Charles N. Harvey III" <ch...@alloy.com>.
> -----Original Message-----
> From: Dave Newton [mailto:dave@solaraccess.com]
>
> I'm currently using a system that uses an XML file to define our
> database tables. The database build and java class generation is
> automagic. Unless the model requires non-generic handling of new fields,
> tables, etc. I rarely have to code anything.
Would you mind letting me know where you found such a system?
I am using OJB and I have been looking at Torque, is that what you
are using to do all this code and database generation? If not, I would
love to find out (if it is publicly available).
Charlie
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: Velocity + Database [long]
Posted by Aaron Freeman <aa...@layerz.com>.
> > 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
point.
Perhaps the name of the script file is the class of the object.
User.sql
--------------------------
<property>
<name>username</name>
SELECT name
FROM users
WHERE unique_user = ${unique_user}
</property>
<method>
<name>addUser</name>
INSERT INTO users
(name, age, date)
WHERE
(${username}, ${age}, ${date})
</method>
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?
-a
RE: Velocity + Database [long]
Posted by Dave Newton <da...@solaraccess.com>.
On Thu, 2003-08-07 at 12:32, Aaron Freeman wrote:
> What is worse is that current MVC implementations require you to recompile
> Java when the database changes! That is much more painful because now a
> simple database change causes the page designer _and_ a Java programmer to
> be involved.
I'm currently using a system that uses an XML file to define our
database tables. The database build and java class generation is
automagic. Unless the model requires non-generic handling of new fields,
tables, etc. I rarely have to code anything.
If the info needs exposure on the presentation layer then the page
designer will be involved anyway. If it's simple form-type stuff then it
should stay in the realm of the page designer; if it's more complicated
than that then I don't see how it would be avoidable under any MVC
scenario.
But if it is, I wanna know how, dangit, 'cuz that'd be useful.
> 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?
> 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?
What does the SQL object look like/do?
> Agreed. Its just too painful to require your Java team to be involved with
> database changes that shouldn't have to involve them. Again, an SQL
> "object" would allow the SQL programmer and page designer to get the job
> done as well.
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 :(
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: Velocity + Database [long]
Posted by Dave Newton <da...@solaraccess.com>.
On Thu, 2003-08-07 at 12:32, Aaron Freeman wrote:
> What is worse is that current MVC implementations require you to recompile
> Java when the database changes! That is much more painful because now a
> simple database change causes the page designer _and_ a Java programmer to
> be involved.
I'm currently using a system that uses an XML file to define our
database tables. The database build and java class generation is
automagic. Unless the model requires non-generic handling of new fields,
tables, etc. I rarely have to code anything.
If the info needs exposure on the presentation layer then the page
designer will be involved anyway. If it's simple form-type stuff then it
should stay in the realm of the page designer; if it's more complicated
than that then I don't see how it would be avoidable under any MVC
scenario.
But if it is, I wanna know how, dangit, 'cuz that'd be useful.
> 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?
> 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?
What does the SQL object look like/do?
> Agreed. Its just too painful to require your Java team to be involved with
> database changes that shouldn't have to involve them. Again, an SQL
> "object" would allow the SQL programmer and page designer to get the job
> done as well.
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 :(
Dave
RE: Velocity + Database [long]
Posted by Aaron Freeman <aa...@layerz.com>.
> The thing to keep in mind that Model in MVC does not actually refer to
> the database system, like JDBC. A database system is a mechanism by
> which we persist the Model.
>
> The idea is that first we model the application's problem domain as
> objects. Objects that are persisted are often referred to as Entity
> Objects, but the Model can also include transient objects.
>
> To persist the Model, we represent it as a series of queries that can be
> applied to a database schema. To visualize the Model, we represent it as
> a series of screens or pages that can be rendered to an output device.
> But neither the database nor the pages are the Model: they are different
> representations of the same Model.
Great points!
> What happens is that many organization put so much effort it modeling
> the problem domain as a database, we often forget that the database is
> not the Model, but merely one representation. The map is not the land.
I don't think organizations necessarily confuse the database with the model.
They are typically trying to generate a robust schema that has proper
business rules in order to maintain stability without relying on another
application such as Java, VB, whatever--I don't even think MVC is in their
mind when the ERD is drafted up. The end result is that the database ends
up being a great representation of the final model, because it incorporates
the same business rules that the model will end up supporting. For example,
a checking account entity has a foreign key reference to a user account.
The implementation of this model will also require the person to have a user
account before they can review a checking account.
> In the rush to market, we have often taken shortcuts and let our page
> representations refer directly to the database representation. As long
> as the database is stable, this isn't a problem. But if the database
> changes, and there is nothing between the page and the database, then
> the pages need to change with it. Likewise, in this type of "model 1"
> arrangement, changes we want to make to the pages sometime imply making
> changes to the database.
What is worse is that current MVC implementations require you to recompile
Java when the database changes! That is much more painful because now a
simple database change causes the page designer _and_ a Java programmer to
be involved.
The same stability issue arises with the JVM as it does with the database.
If the database is properly designed then all will be ok. If the Java
objects are properly designed then all will be ok. The same problem arises
either way.
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.
> In a true MVC implementation, there is a pure-object Application Model
> that mediates between the page model and the database model.
> Essentially, we end up with an adaptor between the page and the
> Application Model and another adaptor between the Application Model and
> the database.
>
> This lets pages be pages and databases be databases. If one
> representation changes, we update its adaptor to the Application Model.
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.
> More importantly, decoupling the representations makes it easier to
> *test* the pages and the database independently of one another. The
> pages or the database can be tested directly against the Application
> Model, without having both running at the same time. We can also swap in
> a mock adaptor to test against a mock database or mock page.
>
> Of course, coding a true Application Model and the adaptors to go with
> it is more work and not always justified by the scope of a project. But
> if the project is enterprise-grade, subject to change, and will be in
> service for many years, an explicit Application layer quickly pays
> dividends.
Agreed. Its just too painful to require your Java team to be involved with
database changes that shouldn't have to involve them. Again, an SQL
"object" would allow the SQL programmer and page designer to get the job
done as well.
> But, there are many, many environments where the database is stable and
> linking the page representation to the database representation is not
> such a bad thing. The vital issue is to get as many of the database
> implementations details out of the VTL as possible. This way, such
> details can be maintained by someone who understands the databases but
> not VTL, AND so that this information can be shared between VTL's.
> Apparently, VeloSurf is trying to do exactly that!
Agreed, however the DDL _and_ the DML need to be decoupled. The DML is
really the adaptor between the page and the database so it should be
referenced via a VTL tag much like a Java object would, but it could still
be placed in a text file somewhere for easy editting by the SQL programmer,
without having to involve a Java programmer.
Am I completely off base here? I don't think this is violating your rules,
just expanding on your adaptor concept.
Aaron Freeman
Layer-Z, Inc.
Phone: (316) 722-8808
Fax: (215) 895-9813
aaron@layerz.com
http://www.layerz.com/
Re: Velocity + Database
Posted by Ted Husted <hu...@apache.org>.
Tim Colson wrote:
> I've taken another [hack] approach lately and added a
> getViewableHashMap() method to my biz entities. This method places the
> objects data into a flat hashmap for the preso layer. This also enables
> the flattening to Person.AddressStreet, but it breaks down for nested
> collections. Ex. if Person contains a collection of addresses and we
> call Person.getViewableHashmap() -> do we expect the data from just
> Person, or also the list of addresses? And then if an Address contains a
> recursive Person object, we must prevent going infinitely deep.
Which are *exactly* the same sort of problems we have to address with
ORM packages -- except in the other direction.
So, something I keep thinking about is a tool that worked like the
Hibernate session but let me map a rich object to a flat transfer
object, and vice versa. It wouldn't surprise me to find one out there,
it's just that the Java Universe is *so* huge now =;0)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Velocity + Database
Posted by Ted Husted <hu...@apache.org>.
Tim Colson wrote:
> I've taken another [hack] approach lately and added a
> getViewableHashMap() method to my biz entities. This method places the
> objects data into a flat hashmap for the preso layer. This also enables
> the flattening to Person.AddressStreet, but it breaks down for nested
> collections. Ex. if Person contains a collection of addresses and we
> call Person.getViewableHashmap() -> do we expect the data from just
> Person, or also the list of addresses? And then if an Address contains a
> recursive Person object, we must prevent going infinitely deep.
Which are *exactly* the same sort of problems we have to address with
ORM packages -- except in the other direction.
So, something I keep thinking about is a tool that worked like the
Hibernate session but let me map a rich object to a flat transfer
object, and vice versa. It wouldn't surprise me to find one out there,
it's just that the Java Universe is *so* huge now =;0)
-Ted.
RE: Velocity + Database [long]
Posted by Tim Colson <tc...@cisco.com>.
Ted -
Thanks for that post - it was an eloquent way of explaining the Model
layer that I'll stuff away to send to other team members.
> Hibernate
> <http://http://sourceforge.net/projects/hibernate> is my
> personal favorite.
+1
> But, sigh, I'm still looking for something that can "flatten" a rich
> object Model into a simple transfer object, so that nested
> objects look
> like top-level properties (Person.Address.Street ->
> Person.AddressStreet).
Agreed.
At one point, I had 'ViewBeans' which were essentially copies of just
the values from my biz objects (similar to Struts ActionForms) but this
involved a lot of copying properties and duplicated getter/setters.
I've taken another [hack] approach lately and added a
getViewableHashMap() method to my biz entities. This method places the
objects data into a flat hashmap for the preso layer. This also enables
the flattening to Person.AddressStreet, but it breaks down for nested
collections. Ex. if Person contains a collection of addresses and we
call Person.getViewableHashmap() -> do we expect the data from just
Person, or also the list of addresses? And then if an Address contains a
recursive Person object, we must prevent going infinitely deep.
This brings me to my question - what have other folks [who are not just
placing the POJO into the context] doing?
Just curious.
Thanks,
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: Velocity + Database [long]
Posted by Tim Colson <tc...@cisco.com>.
Ted -
Thanks for that post - it was an eloquent way of explaining the Model
layer that I'll stuff away to send to other team members.
> Hibernate
> <http://http://sourceforge.net/projects/hibernate> is my
> personal favorite.
+1
> But, sigh, I'm still looking for something that can "flatten" a rich
> object Model into a simple transfer object, so that nested
> objects look
> like top-level properties (Person.Address.Street ->
> Person.AddressStreet).
Agreed.
At one point, I had 'ViewBeans' which were essentially copies of just
the values from my biz objects (similar to Struts ActionForms) but this
involved a lot of copying properties and duplicated getter/setters.
I've taken another [hack] approach lately and added a
getViewableHashMap() method to my biz entities. This method places the
objects data into a flat hashmap for the preso layer. This also enables
the flattening to Person.AddressStreet, but it breaks down for nested
collections. Ex. if Person contains a collection of addresses and we
call Person.getViewableHashmap() -> do we expect the data from just
Person, or also the list of addresses? And then if an Address contains a
recursive Person object, we must prevent going infinitely deep.
This brings me to my question - what have other folks [who are not just
placing the POJO into the context] doing?
Just curious.
Thanks,
Tim
RE: Velocity + Database [long]
Posted by Aaron Freeman <aa...@layerz.com>.
> The thing to keep in mind that Model in MVC does not actually refer to
> the database system, like JDBC. A database system is a mechanism by
> which we persist the Model.
>
> The idea is that first we model the application's problem domain as
> objects. Objects that are persisted are often referred to as Entity
> Objects, but the Model can also include transient objects.
>
> To persist the Model, we represent it as a series of queries that can be
> applied to a database schema. To visualize the Model, we represent it as
> a series of screens or pages that can be rendered to an output device.
> But neither the database nor the pages are the Model: they are different
> representations of the same Model.
Great points!
> What happens is that many organization put so much effort it modeling
> the problem domain as a database, we often forget that the database is
> not the Model, but merely one representation. The map is not the land.
I don't think organizations necessarily confuse the database with the model.
They are typically trying to generate a robust schema that has proper
business rules in order to maintain stability without relying on another
application such as Java, VB, whatever--I don't even think MVC is in their
mind when the ERD is drafted up. The end result is that the database ends
up being a great representation of the final model, because it incorporates
the same business rules that the model will end up supporting. For example,
a checking account entity has a foreign key reference to a user account.
The implementation of this model will also require the person to have a user
account before they can review a checking account.
> In the rush to market, we have often taken shortcuts and let our page
> representations refer directly to the database representation. As long
> as the database is stable, this isn't a problem. But if the database
> changes, and there is nothing between the page and the database, then
> the pages need to change with it. Likewise, in this type of "model 1"
> arrangement, changes we want to make to the pages sometime imply making
> changes to the database.
What is worse is that current MVC implementations require you to recompile
Java when the database changes! That is much more painful because now a
simple database change causes the page designer _and_ a Java programmer to
be involved.
The same stability issue arises with the JVM as it does with the database.
If the database is properly designed then all will be ok. If the Java
objects are properly designed then all will be ok. The same problem arises
either way.
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.
> In a true MVC implementation, there is a pure-object Application Model
> that mediates between the page model and the database model.
> Essentially, we end up with an adaptor between the page and the
> Application Model and another adaptor between the Application Model and
> the database.
>
> This lets pages be pages and databases be databases. If one
> representation changes, we update its adaptor to the Application Model.
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.
> More importantly, decoupling the representations makes it easier to
> *test* the pages and the database independently of one another. The
> pages or the database can be tested directly against the Application
> Model, without having both running at the same time. We can also swap in
> a mock adaptor to test against a mock database or mock page.
>
> Of course, coding a true Application Model and the adaptors to go with
> it is more work and not always justified by the scope of a project. But
> if the project is enterprise-grade, subject to change, and will be in
> service for many years, an explicit Application layer quickly pays
> dividends.
Agreed. Its just too painful to require your Java team to be involved with
database changes that shouldn't have to involve them. Again, an SQL
"object" would allow the SQL programmer and page designer to get the job
done as well.
> But, there are many, many environments where the database is stable and
> linking the page representation to the database representation is not
> such a bad thing. The vital issue is to get as many of the database
> implementations details out of the VTL as possible. This way, such
> details can be maintained by someone who understands the databases but
> not VTL, AND so that this information can be shared between VTL's.
> Apparently, VeloSurf is trying to do exactly that!
Agreed, however the DDL _and_ the DML need to be decoupled. The DML is
really the adaptor between the page and the database so it should be
referenced via a VTL tag much like a Java object would, but it could still
be placed in a text file somewhere for easy editting by the SQL programmer,
without having to involve a Java programmer.
Am I completely off base here? I don't think this is violating your rules,
just expanding on your adaptor concept.
Aaron Freeman
Layer-Z, Inc.
Phone: (316) 722-8808
Fax: (215) 895-9813
aaron@layerz.com
http://www.layerz.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Velocity + Database [long]
Posted by Ted Husted <hu...@apache.org>.
The thing to keep in mind that Model in MVC does not actually refer to
the database system, like JDBC. A database system is a mechanism by
which we persist the Model.
The idea is that first we model the application's problem domain as
objects. Objects that are persisted are often referred to as Entity
Objects, but the Model can also include transient objects.
To persist the Model, we represent it as a series of queries that can be
applied to a database schema. To visualize the Model, we represent it as
a series of screens or pages that can be rendered to an output device.
But neither the database nor the pages are the Model: they are different
representations of the same Model.
What happens is that many organization put so much effort it modeling
the problem domain as a database, we often forget that the database is
not the Model, but merely one representation. The map is not the land.
In the rush to market, we have often taken shortcuts and let our page
representations refer directly to the database representation. As long
as the database is stable, this isn't a problem. But if the database
changes, and there is nothing between the page and the database, then
the pages need to change with it. Likewise, in this type of "model 1"
arrangement, changes we want to make to the pages sometime imply making
changes to the database.
In a true MVC implementation, there is a pure-object Application Model
that mediates between the page model and the database model.
Essentially, we end up with an adaptor between the page and the
Application Model and another adaptor between the Application Model and
the database.
This lets pages be pages and databases be databases. If one
representation changes, we update its adaptor to the Application Model.
More importantly, decoupling the representations makes it easier to
*test* the pages and the database independently of one another. The
pages or the database can be tested directly against the Application
Model, without having both running at the same time. We can also swap in
a mock adaptor to test against a mock database or mock page.
Of course, coding a true Application Model and the adaptors to go with
it is more work and not always justified by the scope of a project. But
if the project is enterprise-grade, subject to change, and will be in
service for many years, an explicit Application layer quickly pays
dividends.
But, there are many, many environments where the database is stable and
linking the page representation to the database representation is not
such a bad thing. The vital issue is to get as many of the database
implementations details out of the VTL as possible. This way, such
details can be maintained by someone who understands the databases but
not VTL, AND so that this information can be shared between VTL's.
Apparently, VeloSurf is trying to do exactly that!
For larger, more dynamic applications, we are now seeing some good
Object Relational Modeling (ORM) tools that provide the adaptor between
the Application Model and the database representation. Hibernate
<http://http://sourceforge.net/projects/hibernate> is my personal favorite.
But, sigh, I'm still looking for something that can "flatten" a rich
object Model into a simple transfer object, so that nested objects look
like top-level properties (Person.Address.Street -> Person.AddressStreet).
-Ted.
Claude Brisson wrote:
> Nathan wrote :
>
>
>>so, yeah, Velosurf already separates SQL from the templates (and in a clean,
>>simple way), but it doesn't separate Model *manipulation* from the View.
>>therein lies the MVC "no-no." of course, if your application involves only
>>presentation (reports and whatnot), then just tell Velosurf to be read-only,
>>and you have a quick and easy way to expose your model to the view for
>>presentation. my understanding is that that would be simple, quick, and
>>legitimate MVC.
>
>
> Good remarks, but since classes mapping database objects can be inherited, you can have your $mypersistententity.delete() make
> anything you want, like generate an event in the framework instead of really deleting the row from the db (which remains the default
> behaviour if not in read-only mode).
>
> In fact, the aim of Velosurf is not to merge the View and Model layers, but to help to expose (parts of) the Model into the View,
> which is more or less needed at some point.
>
> In the next Velosurf release, I'll try to rewrite the docs so as to implicitely drive users towards a better respect of the MVC
> principles.
>
> CloD
>
> ----- Original Message -----
> From: "Nathan Bubna" <na...@esha.com>
> To: "Velocity Users List" <ve...@jakarta.apache.org>
> Sent: dimanche 27 juillet 2003 00:05
> Subject: Re: Velocity + Database
>
>
>
>>Aaron Freeman said:
>>...
>>
>>>Ok, I think a very cool way to do what I was talking about, as well as
>>>accomplish better MVC practices is to add a new VTL directive called #query
>>>that would be placed inside of .vs (velocity SQL [only a best practice
>>>requirement]) files.
>>>
>>>For example inside of a file called user.vs you would have:
>>>#query ( name='getUsersByAge')
>>>SELECT username
>>> FROM users
>>>WHERE age = #age
>>> AND state = #state
>>>#end
>>>
>>>Then in your index.vm you might have:
>>><html>
>>><body>
>>>#foreach ($user in $getUsersByAge.username)
>>>$velocityCount: $user
>>>#end
>>></body>
>>></html>
>>
>>creating this would be a lot of work and would be not much different from
>>Velosurf. frankly, i think Claude's system (defining the querys and entities
>>and whatnot in a separate xml file) is better than this would be, and his
>>system is already created.
>>
>>
>>>By separating the SQL into separate files, that really separates the SQL
>>>programming logic from the View logic, and it makes it very easy on the SQL
>>>programmer ... he doesn't need to know java.
>>
>>eh... i guess i should be clearer. Velosurf doesn't involve putting SQL in
>>templates, but it does have SQL*calls* directly exposed. so in your template,
>>you would do things like $mypersistententity.delete(). in a more typical MVC
>>setup, you would not expose things like that to the template (or whatever view
>>technology you are using). that sort of model manipulation would happen in
>>Java code (usually in business/model logic code that is called from an
>>*action* class of a framework like Struts or Turbine).
>>
>>so, yeah, Velosurf already separates SQL from the templates (and in a clean,
>>simple way), but it doesn't separate Model *manipulation* from the View.
>>therein lies the MVC "no-no." of course, if your application involves only
>>presentation (reports and whatnot), then just tell Velosurf to be read-only,
>>and you have a quick and easy way to expose your model to the view for
>>presentation. my understanding is that that would be simple, quick, and
>>legitimate MVC.
>>
>>Nathan Bubna
>>nathan@esha.com
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Ted Husted,
Junit in Action - <http://www.manning.com/massol/>,
Struts in Action - <http://husted.com/struts/book.html>,
JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
Re: Velocity + Database [long]
Posted by Ted Husted <hu...@apache.org>.
The thing to keep in mind that Model in MVC does not actually refer to
the database system, like JDBC. A database system is a mechanism by
which we persist the Model.
The idea is that first we model the application's problem domain as
objects. Objects that are persisted are often referred to as Entity
Objects, but the Model can also include transient objects.
To persist the Model, we represent it as a series of queries that can be
applied to a database schema. To visualize the Model, we represent it as
a series of screens or pages that can be rendered to an output device.
But neither the database nor the pages are the Model: they are different
representations of the same Model.
What happens is that many organization put so much effort it modeling
the problem domain as a database, we often forget that the database is
not the Model, but merely one representation. The map is not the land.
In the rush to market, we have often taken shortcuts and let our page
representations refer directly to the database representation. As long
as the database is stable, this isn't a problem. But if the database
changes, and there is nothing between the page and the database, then
the pages need to change with it. Likewise, in this type of "model 1"
arrangement, changes we want to make to the pages sometime imply making
changes to the database.
In a true MVC implementation, there is a pure-object Application Model
that mediates between the page model and the database model.
Essentially, we end up with an adaptor between the page and the
Application Model and another adaptor between the Application Model and
the database.
This lets pages be pages and databases be databases. If one
representation changes, we update its adaptor to the Application Model.
More importantly, decoupling the representations makes it easier to
*test* the pages and the database independently of one another. The
pages or the database can be tested directly against the Application
Model, without having both running at the same time. We can also swap in
a mock adaptor to test against a mock database or mock page.
Of course, coding a true Application Model and the adaptors to go with
it is more work and not always justified by the scope of a project. But
if the project is enterprise-grade, subject to change, and will be in
service for many years, an explicit Application layer quickly pays
dividends.
But, there are many, many environments where the database is stable and
linking the page representation to the database representation is not
such a bad thing. The vital issue is to get as many of the database
implementations details out of the VTL as possible. This way, such
details can be maintained by someone who understands the databases but
not VTL, AND so that this information can be shared between VTL's.
Apparently, VeloSurf is trying to do exactly that!
For larger, more dynamic applications, we are now seeing some good
Object Relational Modeling (ORM) tools that provide the adaptor between
the Application Model and the database representation. Hibernate
<http://http://sourceforge.net/projects/hibernate> is my personal favorite.
But, sigh, I'm still looking for something that can "flatten" a rich
object Model into a simple transfer object, so that nested objects look
like top-level properties (Person.Address.Street -> Person.AddressStreet).
-Ted.
Claude Brisson wrote:
> Nathan wrote :
>
>
>>so, yeah, Velosurf already separates SQL from the templates (and in a clean,
>>simple way), but it doesn't separate Model *manipulation* from the View.
>>therein lies the MVC "no-no." of course, if your application involves only
>>presentation (reports and whatnot), then just tell Velosurf to be read-only,
>>and you have a quick and easy way to expose your model to the view for
>>presentation. my understanding is that that would be simple, quick, and
>>legitimate MVC.
>
>
> Good remarks, but since classes mapping database objects can be inherited, you can have your $mypersistententity.delete() make
> anything you want, like generate an event in the framework instead of really deleting the row from the db (which remains the default
> behaviour if not in read-only mode).
>
> In fact, the aim of Velosurf is not to merge the View and Model layers, but to help to expose (parts of) the Model into the View,
> which is more or less needed at some point.
>
> In the next Velosurf release, I'll try to rewrite the docs so as to implicitely drive users towards a better respect of the MVC
> principles.
>
> CloD
>
> ----- Original Message -----
> From: "Nathan Bubna" <na...@esha.com>
> To: "Velocity Users List" <ve...@jakarta.apache.org>
> Sent: dimanche 27 juillet 2003 00:05
> Subject: Re: Velocity + Database
>
>
>
>>Aaron Freeman said:
>>...
>>
>>>Ok, I think a very cool way to do what I was talking about, as well as
>>>accomplish better MVC practices is to add a new VTL directive called #query
>>>that would be placed inside of .vs (velocity SQL [only a best practice
>>>requirement]) files.
>>>
>>>For example inside of a file called user.vs you would have:
>>>#query ( name='getUsersByAge')
>>>SELECT username
>>> FROM users
>>>WHERE age = #age
>>> AND state = #state
>>>#end
>>>
>>>Then in your index.vm you might have:
>>><html>
>>><body>
>>>#foreach ($user in $getUsersByAge.username)
>>>$velocityCount: $user
>>>#end
>>></body>
>>></html>
>>
>>creating this would be a lot of work and would be not much different from
>>Velosurf. frankly, i think Claude's system (defining the querys and entities
>>and whatnot in a separate xml file) is better than this would be, and his
>>system is already created.
>>
>>
>>>By separating the SQL into separate files, that really separates the SQL
>>>programming logic from the View logic, and it makes it very easy on the SQL
>>>programmer ... he doesn't need to know java.
>>
>>eh... i guess i should be clearer. Velosurf doesn't involve putting SQL in
>>templates, but it does have SQL*calls* directly exposed. so in your template,
>>you would do things like $mypersistententity.delete(). in a more typical MVC
>>setup, you would not expose things like that to the template (or whatever view
>>technology you are using). that sort of model manipulation would happen in
>>Java code (usually in business/model logic code that is called from an
>>*action* class of a framework like Struts or Turbine).
>>
>>so, yeah, Velosurf already separates SQL from the templates (and in a clean,
>>simple way), but it doesn't separate Model *manipulation* from the View.
>>therein lies the MVC "no-no." of course, if your application involves only
>>presentation (reports and whatnot), then just tell Velosurf to be read-only,
>>and you have a quick and easy way to expose your model to the view for
>>presentation. my understanding is that that would be simple, quick, and
>>legitimate MVC.
>>
>>Nathan Bubna
>>nathan@esha.com
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Ted Husted,
Junit in Action - <http://www.manning.com/massol/>,
Struts in Action - <http://husted.com/struts/book.html>,
JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Velocity + Database
Posted by Claude Brisson <cl...@savoirweb.com>.
Nathan wrote :
> so, yeah, Velosurf already separates SQL from the templates (and in a clean,
> simple way), but it doesn't separate Model *manipulation* from the View.
> therein lies the MVC "no-no." of course, if your application involves only
> presentation (reports and whatnot), then just tell Velosurf to be read-only,
> and you have a quick and easy way to expose your model to the view for
> presentation. my understanding is that that would be simple, quick, and
> legitimate MVC.
Good remarks, but since classes mapping database objects can be inherited, you can have your $mypersistententity.delete() make
anything you want, like generate an event in the framework instead of really deleting the row from the db (which remains the default
behaviour if not in read-only mode).
In fact, the aim of Velosurf is not to merge the View and Model layers, but to help to expose (parts of) the Model into the View,
which is more or less needed at some point.
In the next Velosurf release, I'll try to rewrite the docs so as to implicitely drive users towards a better respect of the MVC
principles.
CloD
----- Original Message -----
From: "Nathan Bubna" <na...@esha.com>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: dimanche 27 juillet 2003 00:05
Subject: Re: Velocity + Database
> Aaron Freeman said:
> ...
> > Ok, I think a very cool way to do what I was talking about, as well as
> > accomplish better MVC practices is to add a new VTL directive called #query
> > that would be placed inside of .vs (velocity SQL [only a best practice
> > requirement]) files.
> >
> > For example inside of a file called user.vs you would have:
> > #query ( name='getUsersByAge')
> > SELECT username
> > FROM users
> > WHERE age = #age
> > AND state = #state
> > #end
> >
> > Then in your index.vm you might have:
> > <html>
> > <body>
> > #foreach ($user in $getUsersByAge.username)
> > $velocityCount: $user
> > #end
> > </body>
> > </html>
>
> creating this would be a lot of work and would be not much different from
> Velosurf. frankly, i think Claude's system (defining the querys and entities
> and whatnot in a separate xml file) is better than this would be, and his
> system is already created.
>
> > By separating the SQL into separate files, that really separates the SQL
> > programming logic from the View logic, and it makes it very easy on the SQL
> > programmer ... he doesn't need to know java.
>
> eh... i guess i should be clearer. Velosurf doesn't involve putting SQL in
> templates, but it does have SQL*calls* directly exposed. so in your template,
> you would do things like $mypersistententity.delete(). in a more typical MVC
> setup, you would not expose things like that to the template (or whatever view
> technology you are using). that sort of model manipulation would happen in
> Java code (usually in business/model logic code that is called from an
> *action* class of a framework like Struts or Turbine).
>
> so, yeah, Velosurf already separates SQL from the templates (and in a clean,
> simple way), but it doesn't separate Model *manipulation* from the View.
> therein lies the MVC "no-no." of course, if your application involves only
> presentation (reports and whatnot), then just tell Velosurf to be read-only,
> and you have a quick and easy way to expose your model to the view for
> presentation. my understanding is that that would be simple, quick, and
> legitimate MVC.
>
> Nathan Bubna
> nathan@esha.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
Re: Velocity + Database
Posted by Claude Brisson <cl...@savoirweb.com>.
Nathan wrote :
> so, yeah, Velosurf already separates SQL from the templates (and in a clean,
> simple way), but it doesn't separate Model *manipulation* from the View.
> therein lies the MVC "no-no." of course, if your application involves only
> presentation (reports and whatnot), then just tell Velosurf to be read-only,
> and you have a quick and easy way to expose your model to the view for
> presentation. my understanding is that that would be simple, quick, and
> legitimate MVC.
Good remarks, but since classes mapping database objects can be inherited, you can have your $mypersistententity.delete() make
anything you want, like generate an event in the framework instead of really deleting the row from the db (which remains the default
behaviour if not in read-only mode).
In fact, the aim of Velosurf is not to merge the View and Model layers, but to help to expose (parts of) the Model into the View,
which is more or less needed at some point.
In the next Velosurf release, I'll try to rewrite the docs so as to implicitely drive users towards a better respect of the MVC
principles.
CloD
----- Original Message -----
From: "Nathan Bubna" <na...@esha.com>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: dimanche 27 juillet 2003 00:05
Subject: Re: Velocity + Database
> Aaron Freeman said:
> ...
> > Ok, I think a very cool way to do what I was talking about, as well as
> > accomplish better MVC practices is to add a new VTL directive called #query
> > that would be placed inside of .vs (velocity SQL [only a best practice
> > requirement]) files.
> >
> > For example inside of a file called user.vs you would have:
> > #query ( name='getUsersByAge')
> > SELECT username
> > FROM users
> > WHERE age = #age
> > AND state = #state
> > #end
> >
> > Then in your index.vm you might have:
> > <html>
> > <body>
> > #foreach ($user in $getUsersByAge.username)
> > $velocityCount: $user
> > #end
> > </body>
> > </html>
>
> creating this would be a lot of work and would be not much different from
> Velosurf. frankly, i think Claude's system (defining the querys and entities
> and whatnot in a separate xml file) is better than this would be, and his
> system is already created.
>
> > By separating the SQL into separate files, that really separates the SQL
> > programming logic from the View logic, and it makes it very easy on the SQL
> > programmer ... he doesn't need to know java.
>
> eh... i guess i should be clearer. Velosurf doesn't involve putting SQL in
> templates, but it does have SQL*calls* directly exposed. so in your template,
> you would do things like $mypersistententity.delete(). in a more typical MVC
> setup, you would not expose things like that to the template (or whatever view
> technology you are using). that sort of model manipulation would happen in
> Java code (usually in business/model logic code that is called from an
> *action* class of a framework like Struts or Turbine).
>
> so, yeah, Velosurf already separates SQL from the templates (and in a clean,
> simple way), but it doesn't separate Model *manipulation* from the View.
> therein lies the MVC "no-no." of course, if your application involves only
> presentation (reports and whatnot), then just tell Velosurf to be read-only,
> and you have a quick and easy way to expose your model to the view for
> presentation. my understanding is that that would be simple, quick, and
> legitimate MVC.
>
> Nathan Bubna
> nathan@esha.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Velocity + Database
Posted by Nathan Bubna <na...@esha.com>.
Aaron Freeman said:
...
> Ok, I think a very cool way to do what I was talking about, as well as
> accomplish better MVC practices is to add a new VTL directive called #query
> that would be placed inside of .vs (velocity SQL [only a best practice
> requirement]) files.
>
> For example inside of a file called user.vs you would have:
> #query ( name='getUsersByAge')
> SELECT username
> FROM users
> WHERE age = #age
> AND state = #state
> #end
>
> Then in your index.vm you might have:
> <html>
> <body>
> #foreach ($user in $getUsersByAge.username)
> $velocityCount: $user
> #end
> </body>
> </html>
creating this would be a lot of work and would be not much different from
Velosurf. frankly, i think Claude's system (defining the querys and entities
and whatnot in a separate xml file) is better than this would be, and his
system is already created.
> By separating the SQL into separate files, that really separates the SQL
> programming logic from the View logic, and it makes it very easy on the SQL
> programmer ... he doesn't need to know java.
eh... i guess i should be clearer. Velosurf doesn't involve putting SQL in
templates, but it does have SQL*calls* directly exposed. so in your template,
you would do things like $mypersistententity.delete(). in a more typical MVC
setup, you would not expose things like that to the template (or whatever view
technology you are using). that sort of model manipulation would happen in
Java code (usually in business/model logic code that is called from an
*action* class of a framework like Struts or Turbine).
so, yeah, Velosurf already separates SQL from the templates (and in a clean,
simple way), but it doesn't separate Model *manipulation* from the View.
therein lies the MVC "no-no." of course, if your application involves only
presentation (reports and whatnot), then just tell Velosurf to be read-only,
and you have a quick and easy way to expose your model to the view for
presentation. my understanding is that that would be simple, quick, and
legitimate MVC.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: Velocity + Database
Posted by Aaron Freeman <aa...@layerz.com>.
> I agree, what you want to do is probably quicker and simpler for *initial*
> development, especially when you're the only one working on the project.
> however, it may easily become much more difficult to maintain, upgrade, or
> debug. it will make it more difficult to divide up various
> portions of the
> development process among multiple people.
Ok, this discussion forced me to go get a book and read up on MVC. Now I
have a clue.
> though i'm by no means an expert on the various paradigms (Model
> 1, Model 2,
> HMVC, Pull-MVC, etc.) or a diehard MVC purist, i agree with the basic
> principle. the primary idea of MVC design is the separation of
> the "model"
> (underlying data structure and logic) from the "view" (user
> interface). it's
> all about the separation of concerns, which allows for more
> efficient division
> of labor, simplifies testing, and makes it easier to replace or
> upgrade one
> piece of your app without having to mess with all of it. putting
> SQL calls
> (deep part of the model) directly into a velocity template (the
> view layer) is
> basically throwing MVC design to the wind. personally, i think that's
> probably fine to do for small projects sometimes, but that's not
> in keeping
> with the aims of the velocity-tools project.
>
> oh, and MVC doesn't really have anything to do with Java. it's a design
> paradigm that's often useful/wise for any language and for the
> desktop as much
> as the web.
Ok, I think a very cool way to do what I was talking about, as well as
accomplish better MVC practices is to add a new VTL directive called #query
that would be placed inside of .vs (velocity SQL [only a best practice
requirement]) files.
For example inside of a file called user.vs you would have:
#query ( name='getUsersByAge')
SELECT username
FROM users
WHERE age = #age
AND state = #state
#end
Then in your index.vm you might have:
<html>
<body>
#foreach ($user in $getUsersByAge.username)
$velocityCount: $user
#end
</body>
</html>
By separating the SQL into separate files, that really separates the SQL
programming logic from the View logic, and it makes it very easy on the SQL
programmer ... he doesn't need to know java.
Just my two cents.
-a
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Velocity + Database
Posted by Nathan Bubna <na...@esha.com>.
Aaron Freeman said:
> Nathan said:
> > Aaron Freeman said:
> > > Are there any Velocity tool sets that allow you to write your
> > database SQL
> > > inside your .vm templates instead of having to bury the SQL
> > code inside of
> > > servlets?
> > ...
...
> > fyi: this is generally considered a really big no-no for MVC development.
>
> How come? I don't fully understand the MVC paradigm yet. It would seem
> easier on the surface if an SQL programmer didn't have to know Java? Is
> there an implicit (or even explicit) understanding that MVC dictates that
> the Controller has to be Java? Sorry, this is a newbie question again ...
> sheesh I have really been out of touch! :)
I agree, what you want to do is probably quicker and simpler for *initial*
development, especially when you're the only one working on the project.
however, it may easily become much more difficult to maintain, upgrade, or
debug. it will make it more difficult to divide up various portions of the
development process among multiple people.
though i'm by no means an expert on the various paradigms (Model 1, Model 2,
HMVC, Pull-MVC, etc.) or a diehard MVC purist, i agree with the basic
principle. the primary idea of MVC design is the separation of the "model"
(underlying data structure and logic) from the "view" (user interface). it's
all about the separation of concerns, which allows for more efficient division
of labor, simplifies testing, and makes it easier to replace or upgrade one
piece of your app without having to mess with all of it. putting SQL calls
(deep part of the model) directly into a velocity template (the view layer) is
basically throwing MVC design to the wind. personally, i think that's
probably fine to do for small projects sometimes, but that's not in keeping
with the aims of the velocity-tools project.
oh, and MVC doesn't really have anything to do with Java. it's a design
paradigm that's often useful/wise for any language and for the desktop as much
as the web.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: Velocity + Database
Posted by Aaron Freeman <aa...@layerz.com>.
> Aaron Freeman said:
> > Are there any Velocity tool sets that allow you to write your
> database SQL
> > inside your .vm templates instead of having to bury the SQL
> code inside of
> > servlets?
> ...
>
> though i've not used it, my understanding is that Claude's
> Velosurf project
> provides this functionality:
> http://www.sf.net/projects/velosurf
Cool, I will check it out!
> fyi: this is generally considered a really big no-no for MVC development.
How come? I don't fully understand the MVC paradigm yet. It would seem
easier on the surface if an SQL programmer didn't have to know Java? Is
there an implicit (or even explicit) understanding that MVC dictates that
the Controller has to be Java? Sorry, this is a newbie question again ...
sheesh I have really been out of touch! :)
> > If not this would be an extremely cool servlet/tool to add to Velocity's
> > tool set.
>
> not in everyone's opinion. :)
I am naive of the bigger picture I think.
-a
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Velocity + Database
Posted by Nathan Bubna <na...@esha.com>.
Aaron Freeman said:
> Are there any Velocity tool sets that allow you to write your database SQL
> inside your .vm templates instead of having to bury the SQL code inside of
> servlets?
...
though i've not used it, my understanding is that Claude's Velosurf project
provides this functionality:
http://www.sf.net/projects/velosurf
fyi: this is generally considered a really big no-no for MVC development.
> If not this would be an extremely cool servlet/tool to add to Velocity's
> tool set.
not in everyone's opinion. :)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org