Re: Using JSTL tags instead of Struts tags

[David Geary]

On Thursday, Jul 10, 2003, at 13:39 America/Denver, Joe Zendle wrote:

Yes, if every datasource in the universe is a set of tables in which 
the
schema never changes ;-)
Schema changes will be felt somewhere in your app, no matter how you 
read the database. It's true that industrial-strength apps shouldn't 
expose database schema to their views, but not all applications require 
that level of decoupling.

It would be an interesting exercise to encapsulate database access in 
JSP fragments. You could still decouple the database schema from your 
views, but your fragments could use JSTL, which is considerably easier 
than JDBC or EJBs.

david
-----Original Message-----
From: David Geary [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 10, 2003 1:11 PM
To: Struts Users Mailing List
Subject: Re: Using JSTL tags instead of Struts tags
On Thursday, Jul 10, 2003, at 12:34 America/Denver, Yuan, Saul (TOR-ML)
wrote:


I started using JSTL but found that it encouraged site builders to
start embedding logic in JSP's.
I'd sure be interested in some examples of this.  JSTL doesn't really
provide anything more than what you could do yourself with scriptlets
and
runtime expressions -- indeed, it's a lot LESS than what you could do
with
those things, in addition to doing it much more succinctly.
JSTL does have a few tags that deal with the backend, say the query
tag:
<sql:query ..., with this you can pull data directly in a Jsp page
without going through a controller layer. But this doesn't necessarily
mean JSTL encourage you to do it this way.
JSTL's SQL tags are unfairly maligned, IMO. If you stay away from
<sql:update> and <sql:transaction>, which clearly break MVC protocol*,
your views can pull data from the model and display it (which is what
views are supposed to do) with <sql:query> and the param tags.
david

*because the views are modifying the model (database)

Saul

I guess you could say my viewpoint on this is exactly the opposite.

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]