Dmitri Namiot wrote:
> yes, yes Craig ! That is exactly what we are doing
> (or trying to do :-) What we need from servers dynamic
> (in my opinion of course) is just ability to load
> classes/run methods. The product we are using (alaJSP)
> is all about that.
And of course, JSP and servlets both let you do that (dynamically load classes and run
methods
in them).
>
> But in my opinion this approach is hided by JSP specs/documents
> contains a lot of stuff that really belongs to servlets.
> Looks like JSP trying to have all relevant stuff from ASP
> world but do you really need that ? It is a nightmare to
> support big ASP projects.
One of the things that I've come to understand much better while studying the servlet
and JSP
specifications is that there really is more than one model of development that makes
sense;
there is more than one level of developer expertise that a platform needs to cater to;
and
there are people who just plain have different preferences about the language(s) they
use. To
be popular, a platform like servlets+JSP needs to accomodate as many of these
differences as
possible, without creating insurmountable conflicts in goals.
Putting things a little bit simplisticly, there are two fundamental world views about
how to
create web based applications: programmer-centric ("the code is the thing -- the user
interface is fluff") or presentation-centric ("the user interface is most important;
logic is
just a little scripting thrown in because it's required"). Where you are usually
depends on
where you came from (programming or HTML page development). The challenge is, can we
define a
technology that meets the needs of both world views without creating a mess, so that
the
result is better than a programming language with gadgets to create HTML, or a page
authoring
tool that integrates some proprietary scripting capability.
Do JSPs sound a lot like servlets? Sure they do -- after all, the compiled version of
a JSP
page *is* a servlet, and it makes a ton of sense to leverage all of the knowledge and
experience that already existed by the time JSP pages came around. It would have been
really
silly to re-invent concepts like session management, forwarding and including pages,
extracting request parameters, and all of that. The fact that servlets and JSPs share
so much
underlying stuff creates a synergy that doesn't exist at the extremes of the two world
views,
because I can seamlessly use both of them.
Does JSP look a lot like ASP? Sure it does -- after all, JSP is by no means the first
syntax
for incorporating presentation logic and scripting. The JSP designers clearly looked
at ASP
and used the good things, and learned from some of the mistakes. The fact that there
are
analogous mechanisms to do most of what ASP provides is also helpful when
ASP-knowledgeable
developers are asked to switch to JSP -- they can map the concepts they are familar
with into
the new syntax without having to learn everything from scratch.
Can you create unmaintainable JSP-based applications? Of course you can. That's why I
evangelize for a design pattern (separate business logic and presentation logic) that
minimizes the most common causes of problems. But you can create just as much
unmaintainable
crap in any language -- including Java -- so that does not seem to me to be a reason
to avoid
features. I'd much rather have a very powerful toolkit, and learn to use it
carefully, than
to have to do the programming equivalent of cutting a board with a hand saw because I
don't
know how to use a power saw safely.
> And for example what are you doing
> with taglibs ? How these elements can be placed in your
> model splited html/java ? And lacking of that explanation is
> a reason of question we are talking about.
>
In the short term, I plan to use custom tag extensions for the following purposes:
* Create some functional logic components (like loops)
that I still use scriptlets for currently. These components
will make it easier for page-designers to start adding
dynamic functionality to their pages, without having to
learn all the messy syntax details of scripting syntax. They
still are focused on the logic needed for presentation, not
the logic needed for model manipulation.
* Create some taglib components that render the
HTML (or XML) presentation of a particular Java object.
(Note: this will still be a separate class from the object
itself -- maintaining view vs. model separation.)
Sometimes I find myself still using scriptlets, especially
when rendering a complex SELECT item or converting
from internal representations (like dates) to Strings.
* Create some "macro" components that allow me to
specify presentation details that are used repeatedly
in only one place -- sort of the same idea as what
style sheets let you do, but on a slightly higher level.
The fact that custom tag components can share
information behind the scenes (via the PageContext)
can hide a lot of complexity as well.
Longer term, I also view custom tag attributes as a mechanism to include custom
components
into a page in a safer way than via scriptlets. Right now, the defined way to
integrate
components is <jsp:useBean>. That's fine, but it tends to cast these components in a
somewhat
passive role. Sometimes there is a lot more complexity in creating the "view" of
something
than there is in creating the "model." Over time, I'm sure that new and innovative
design
patterns using these things will emerge.
>
> And your as well very strong explanation (used much more clear
> English then my :-) as seems to me shows the real way to use JSP.
>
I'm glad you found my explanations clear, but I hesitate a little when people claim
that this
way, or any way, is *the* real way to use JSP. I hope to be able to explain
rationally why
I've chosen the patterns I use, but in fact this is not the only "right" way. But it
is a way
that seems to have a pretty solid theoretical basis, and reflects the experience I've
had in
maintaining and enhancing existing applications. I actively strive to avoid things
that have
caused me grief in the past, and intermixed business and presentation logic is
definitely one
of those things -- no matter what language or development platform I'm using.
Craig
PS: One quick note about specifications -- I know how frustrating it is to try to
learn a new
technology by reading things like the servlet and JSP specs, but you need to remember
that
users are not the primary target audience of those documents. The specs have to be
clear to
those who *implement* these things, to maintain the portability we all care about.
That
leaves a whole lot of room for writers of all persuasions to fill the knowledge gap
for users
with discussions of *how* to use this stuff, and *why* it is or isn't specified in a
particular way. But that kind of discussion would obscure the *what* knowledge that
implementors need. As time goes on, you're starting to see more articles, books, and
mailing
list discussions to illuminate the stuff users care more about. But this process
takes a
while to happen. That's part of the price, and the fun, of playing on the cutting
edge :-).
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
