Joe,

We are talking about different things. Struts is MVC. JSP, JSTL, 
JSF, etc. are just the V. If you don't use something like Struts, 
you will never be able to switch the view. I bet your PBD tool 
does not work with program defined display files. For the same 
reasons, you are better off using Struts and JSTL tags over 
scriptlets or pure HTML.

I can't afford to stop development and wait for JSF. I have 
used JSF enough to know that it isn't everything I want 
today and never will. I will be using JSF where it makes 
sense very soon after a Tomcat 5.0 release is available. 
JSF also has some gaps that Struts fills. It is very easy to 
convert most Struts application to take advantage of JSF. It 
is possible to make it difficult by using scriptlets, not using MVC, 
etc.

My ideal framework would implement MVC as a services 
interface over a platform independent database layer (like 
Hibernate provides). The view would be pluggable and 
implemented as a pipeline. The controller would be defined 
with XML and support state based workflow. Jelly is a technology 
that provides most of what you would need for the view and 
controller. A framework like that could easily combine J#, 
java, etc. for model support with swing, http, SWT for the 
view. I have done enough prototyping with tools like Jelly 
and Axis to know that it would work.

If you are set on using scriptlets, you might look at: 
http://www.day.com/en/product/productline/unify/ide/dnlogin.html 
I don't know if it is any good but I do know that debugging scriptlets

is a huge pain.


David Morris

>>> joepluta@xxxxxxxxxxxxxxxxx 10/9/2003 4:58:53 PM >>>
> From: David Morris
> 
> There are lots of ways but most commonly it is going to
> look something like:
> 
> <html-el:text property="customer.name"
> onchange="myJavaScriptFunction(this)"/>

Actually, I was just trying to figure out the ID of the element so
that
I could do it dynamically.  I'm sure it's relatively simple.

Anyway, you can do what you want.  I think Struts is a moving target
and
I doubt it will stick around.  In fact, you're already saying the same
thing yourself by sticking in JSTL code.  In fact, to quote one
source:

"Another thing to watch for is the eventual deprecation of the Struts
tag libraries. The Struts taglibs largely date from before JSTL was
available, and most of their functionalities can be better served by
the
equivalent JSTL tags at this point. As JSTL-compatible (Servlet 2.3)
containers become the standard (such as Tomcat 4.0), there will be
less
and less reason to use (and, by extension, to maintain and improve)
the
Struts tag libraries.

Eventually, Struts may find itself out of a job. As the JSF standard
evolved over the last year, more and more of the Struts functionality
crept into JSF. This is not surprising, considering that Craig
McClanahan, the "father" of Struts, is also the JSF Spec Lead. Because
JSF is a JCP technology, it will be widely adopted and may eventually
push out Struts because there is a lot of overlap between the two. Of
course, the Struts development community is already busily discussing
how to keep Struts relevant in a post-JSF world, and you can also
expect
tools to provide cross-compatibility and migration from Struts to JSF
after JSF is available for production applications (again, in 2004.)"

That's from this article: 

http://www.informit.com/isapi/product_id~%7B316CC9BC-0628-4099-BF44-C1E8

69E73852%7D/content/index.asp

Who knows, maybe I'm wrong.  But I kinda think this guy has it pegged.
Struts will be replaced by JSF and JSTL.  The question is, what will
JSF
and JSTL be replaced by?

My point? If you just code to the basic JSP syntax, you don't care.

Joe

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.