> Speaking of tools, I continue to advocate that we need a JSP interpreter
> during the development time. I'm tired of waiting for my JSP and tag
> files to compile, every time I make a little modification. It's just not
> productive at all.
I have two thoughts on that.
Foremost, I have found it to be far more productive to establish a test
framework (ala Jasper+JUnit+jMock+HtmlUnit) for the JSP components just
like you would for other components. I agree that the "edit, compile,
reload" is painful, but so is doing the same thing with an EJB.
There are two schools of thought on this kind of thing:
* I want the iterations to go faster or
* I want to be more sure that what I'm putting out there works right
the first time.
The first point leans more toward a scripting language (LAMP) camp. One
can escape the compilation time in a LAMP environment. This is the
fast-and-loose crowd.
The second point calls out the _advantages_ that a strongly-typed
language (such as Java) brings to the table. The compiler spends all of
its time enforcing contracts between components. Test cases (of various
granularity and component boundaries) let one sleep better at night
knowing (to the best of your ability) the component does what it is
supposed to do.
My second thought is about one way of going about what you asked for,
ever how misguided I may feel it is. The XML syntax (JSP.10.1, et al) is
perfect for interpretation. In contrast to the much more "free form"
Java syntax, XML syntax is better suited to extensive verification and
in-memory manipulation. This assumes that one is not [ab]using
jsp:scriptlet blocks, but isn't that what MVC has been trying to teach
us for years?
In conclusion, I would argue that in the realm of JSP development, we
don't need a new way of development, we need to better employ the
existing ones.
My USD$0.02,
-- /v\atthew