My point is that if you want to cross multiple vendor barriers, use web services (Service Oriented Architecture). You are going to have to do this, anyway, within a year, so start getting used to the idea.
Mark btw: that was funny. -----Original Message----- From: Joe Zendle [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 5:50 PM To: Struts Users Mailing List Subject: RE: Using JSTL tags instead of Struts tags I think it's time for your lithium! -----Original Message----- From: Mark Galbreath [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 3:44 PM To: 'Struts Users Mailing List' Subject: RE: Using JSTL tags instead of Struts tags Then abstract your classes from the underlying protocol using interfaces and implement an SOA solution. Mark -----Original Message----- From: Joe Zendle [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 5:42 PM To: Struts Users Mailing List Subject: RE: Using JSTL tags instead of Struts tags The main point is that not every data source is an RDBMS. Yes, if you are writing a medium sized app that will *always* be hosted on an RDBMS then the sql tags are very powerful and nicely alleviate the god-awful impedence mismatch. Many schema changes are made to denormalize data for performance reasons (3rd normal form be damned :-). These changes are usually made later in the development cycle as performance issues rear their ugly heads. The actual data to be presented to the user does *not* change one bit however every jsp that accesses the DB directly must change per the new schema (unless a view is used) due to the tight coupling. Quite a nightmare. I think the jstl xml tags are perfect for the decoupling layer that you refer to. The view does not care where the xml comes from, be it RDBMS, dbm, flatfile, legacy system, CORBA, EJB, etc. Cheers. -----Original Message----- From: David Geary [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 3:00 PM To: Struts Users Mailing List Subject: Re: Using JSTL tags instead of Struts tags 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] --------------------------------------------------------------------- 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]
