jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph B. Ottinger" <j...@epesh.com>
Subject best practices (follow-up to the roadmap thread)
Date Sun, 24 Dec 2000 19:46:16 GMT
The bottom line is: How do we see JSP being used in the future? Are we
targeting people used to workarounds like PHP, enabling people who think
HTML is an able programming language, and helping web designers create
their content? Or are we implementing a tool for application designers,
creating loosely-coupled components geared at helping enterprise-level
designers focus on their problem domains rather than on the rudiments of
transformation of data, creating items aimed at proper design?

I say the latter. I do not control JSP, nor do I control its future, but I
see a recent thrust towards aiming at the lowest common denominator - the
HTML author. I think this is a mistake. JSP is not HTML. People whose
skills sets stretch only to HTML - and I think the number of these people
is lower than we believe - aren't writing active content. They're writing
HTML. Writing "email tags for dummies" doesn't help either the dummies
(who don't know what an SMTP server is) or those who might otherwise need
such components, because I, for example, might need more flexibility than
a simple designer would, but an overly simplistic tool - or even a
simplistic access paradigm - means that I can't reuse, but I get to
reimplement instead. In addition, even in cases where the simple baseline
is enough, I don't have a good example of proper design, so when it comes
time that I might design a flexible, useful component myself, all I have
for examples are simplistic, tightly coupled (to HTML) templates. Want to
store your data in resources? Great - but *I* use a database, and since I
do, that's what I gear for. What other example is there other than aiming
at specifically what *I* do instead of what I *might* do?

Of course, the response is that I can use JSP's expression syntax to plug
data in. That's certainly better than not being able to plug data in, but
I don't think it goes far enough. Body content is more flexible, more
simple to all but the tag designer (and those who count keystrokes, like
us poor vi users - oh, wait, I use vi, but I don't count keystrokes!) More
tags mean more typing, sure, and more flexibility. I'll take the trade,
especially as tools come online to make JSP for dummies (and the
not-so-dumb) easier.

Bottom line: I think that aiming tags at generating HTML *like* HTML isn't
a brilliant idea. Let's look ahead and bring the future to life, rather
than take the easy way at every step. Let's spend the effort now and keep
JSP as an enterprise-ready solution, instead of yet-another-way to
generate simple HTML.

As an aside:

JSPT is a neat idea... but I think you can see my thoughts: It's geared
towards generating content, which may be fine but is hardly all I see tags
doing. JSPT only cured part of the problem.

-----------------------------------------------------------
Joseph B. Ottinger                           joeo@epesh.com
http://epesh.com/                             IT Consultant


Mime
View raw message