Am I the only one who questions JSTL, Struts Tags, XSL Tags?

[Greg Smith]

in our office i recently vented about the constant reintroduction of
the IF/WHILE/FOR/FOREACH tags in <c:> and <x:> and other taglibs.
IMHO, it is a terrible affront to the Java language. We already have
If/While/For/Foreach in Java, adding it to every taglib dilutes the
language.

Essentially, a taglib is an extension to HTML. I feel that having
multiple IF statements weakens the programming environment. Why not
just use Java's IF. Extending HTML to allow control structures
attempts to make HTML a programming language - which it is not. It is
a markup language. And a pretty decent one at that. But HTML does
not lend itself well to describing programming constructs, in
particular flow control.

Am I alone in this?

 

[Ben_]

The problem with java scriptlets and declarations in JSP is that it is
considered to make the source more difficult to read, non-XML and it opens
the door to the fanciest thing a developer can code.

As it is considered bad practice to code in a JSP, the JSP spec has evolved
to make the source an XML file and taglibs have appeared to make the java
code disappear from the JSP.

There is actually a need for tests and iterations in JSP, hence the need for
the corresponding taglibs.

Is it an "offense" to the language that taglibs have gone to the JCP and
have been intregrated in J2EE ? I don't think so, because the embracement by
the community of developers and the recognition of the existence of this
need by the JCP is the sign that there is a place for it.

OTOH, it's always possible to abuse things. And like it is possible to abuse
JSP by placing much java logic in it, it is possible to abuse taglibs.

Ben.

 

[Tor Iver Wilhelmsen]

Is it an "offense" to the language that taglibs have gone to the JCP and
have been intregrated in J2EE ? I don't think so, because the embracement by
the community of developers and the recognition of the existence of this
need by the JCP is the sign that there is a place for it.

The problem with cramming all that stuff into J2EE is: If a potential
employer wants J2EE skills, what does he really want? JDBC? EJBs?
Servlets? JSPs? JNDI? SOAP?

It's much clearer when the technologies are separated.

 

[John Harlow]

in our office i recently vented about the constant reintroduction of
the IF/WHILE/FOR/FOREACH tags in <c:> and <x:> and other taglibs.
IMHO, it is a terrible affront to the Java language. We already have
If/While/For/Foreach in Java, adding it to every taglib dilutes the
language.

Essentially, a taglib is an extension to HTML. I feel that having
multiple IF statements weakens the programming environment. Why not
just use Java's IF. Extending HTML to allow control structures
attempts to make HTML a programming language - which it is not. It is
a markup language. And a pretty decent one at that. But HTML does
not lend itself well to describing programming constructs, in
particular flow control.

Am I alone in this?

<rant>
I would like to shoot the person who suggested the <input> tag should have
eve been added to HTML. HTML is a great BROWSING format for BROWSERS which
were not designed for INTERACTIVE DATA ENTRY applications.

So now we have silly "rigs" to deal with like tags, cookies and client side
javascript, and ridiculous hoops to jump through because the connectionless
server can't push stuff to the client and caches stuff when we don't want it
to and multiple flavors of browsers etc.
</rant>

For now we're stuck with taglibs or some other directives to have the server
build the HTML. I have devised a MUCH more efficient way of doing things in
my server design, but it still requires some "hints" in the HTML for the
server to dynamically build the HTML.

Someday maybe the IT world will wake up and see how silly it is to force
this HTML round peg into an interactive application square hole.

 

[Will Hartung]

in our office i recently vented about the constant reintroduction of
the IF/WHILE/FOR/FOREACH tags in <c:> and <x:> and other taglibs.
IMHO, it is a terrible affront to the Java language. We already have
If/While/For/Foreach in Java, adding it to every taglib dilutes the
language.

Essentially, a taglib is an extension to HTML. I feel that having
multiple IF statements weakens the programming environment. Why not
just use Java's IF. Extending HTML to allow control structures
attempts to make HTML a programming language - which it is not. It is
a markup language. And a pretty decent one at that. But HTML does
not lend itself well to describing programming constructs, in
particular flow control.

I like the tag libs, I think they're cleaner to use, easier to scan for, and
they behave well with most editors.

Also, you're not jumping mindsets back and forth from Scriptlet to HTML and
back. It helps keep things at a high level. When you combine high level
taglibs for branch, with other high level tags (like Tiles), it makes for a
clean page layout that's easy to follow. I find embedded code difficult to
grok normally, indenting is all wrong, etc.

Finally it lets my HTML Mind pretty much stay out of the Java Mind, and also
makes it easier for "pure" HTML folks to work with. Just give them the tag
libs, and a list of properties to stich together, and with the Expression
Language, I think it comes out pretty well.

Regards,

Will Hartung
([email protected])

 

[Will Hartung]

I would like to shoot the person who suggested the <input> tag should have
eve been added to HTML. HTML is a great BROWSING format for BROWSERS which
were not designed for INTERACTIVE DATA ENTRY applications.

So now we have silly "rigs" to deal with like tags, cookies and client side
javascript, and ridiculous hoops to jump through because the connectionless
server can't push stuff to the client and caches stuff when we don't want it
to and multiple flavors of browsers etc.
</rant>

For now we're stuck with taglibs or some other directives to have the server
build the HTML. I have devised a MUCH more efficient way of doing things in
my server design, but it still requires some "hints" in the HTML for the
server to dynamically build the HTML.

The problem isn't the markup language, it's simply the whole paradigm of
stateless, page oriented design. If Swing worked the same way, you'd hate it
just as much, only there the markup language is Java instead of
HTML/Javascript.

Regards,

Will Hartung
([email protected])

 

[The Abrasive Sponge]

in our office i recently vented about the constant reintroduction of
the IF/WHILE/FOR/FOREACH tags in <c:> and <x:> and other taglibs.
IMHO, it is a terrible affront to the Java language. We already have
If/While/For/Foreach in Java, adding it to every taglib dilutes the
language.

Essentially, a taglib is an extension to HTML. I feel that having
multiple IF statements weakens the programming environment. Why not
just use Java's IF. Extending HTML to allow control structures
attempts to make HTML a programming language - which it is not. It is
a markup language. And a pretty decent one at that. But HTML does
not lend itself well to describing programming constructs, in
particular flow control.

Am I alone in this?

yep

 

[John Harlow]

The problem isn't the markup language, it's simply the whole paradigm

of stateless, page oriented design.

I'm pretty sure this is exactly what I said; we have to live with the
hodgepodge mess of a browser based markup languaged being forced to attempt
to emulate client / server style apps. It's a rig at best, and it's costing
companies far more than all viruses put together.

 

[Will Hartung]

I'm pretty sure this is exactly what I said; we have to live with the
hodgepodge mess of a browser based markup languaged being forced to attempt
to emulate client / server style apps. It's a rig at best, and it's costing
companies far more than all viruses put together.

You're blaming the markup language. The markup language has nothing to do
with the problem. If I had to download a block of Java, VB code, English,
Sanskrit, COBOL or INTERCAL everytime I wanted to do something to the
screen, it would still suck.

Client/Server apps (i.e. "thick" clients, now "Rich" clients) rely on more
client side state and finer interaction with the back end than typical
browser based app do today.

Technically, you could write a Client/Server app (with a bit of tomfoolery)
in pure Javascript over HTTP. Probably wouldn't be very secure though.

Regards,

Will Hartung
([email protected])

 

[Sudsy]

"Greg Smith" <[email protected]> wrote in message

It's a matter of separating mark-up from content and it's the best
approach I've seen, IMHO.

Also, you're not jumping mindsets back and forth from Scriptlet to HTML and
back. It helps keep things at a high level. When you combine high level
taglibs for branch, with other high level tags (like Tiles), it makes for a
clean page layout that's easy to follow. I find embedded code difficult to
grok normally, indenting is all wrong, etc.

Finally it lets my HTML Mind pretty much stay out of the Java Mind, and also
makes it easier for "pure" HTML folks to work with. Just give them the tag
libs, and a list of properties to stich together, and with the Expression
Language, I think it comes out pretty well.

I'm with Will on this one. OP: you might want to consider that the
output from JSPs is HTML (or XML or DHTML) which can be rendered
in a browser. IOW you're dealing with the "presentation" layer.
Having logical constructs available in the templates which the end-
user will never see hardly pollutes the intent.
I'll take tags over scriptlets any day!
YMMV

 

[Ben_]

The problem with cramming all that stuff into J2EE is: If a potential

employer wants J2EE skills, what does he really want? JDBC? EJBs?
Servlets? JSPs? JNDI? SOAP?

It's much clearer when the technologies are separated.

I understand it a bit differently.

All the technologies are usable independently, in the sense that you are not
obliged to use all of them and you can find products that implement only a
subset of J2EE. You can do JSP/servlet without EJB's or the other way round,
you can do JDBC in a Swing application, you invoke SOAP from any client,
etc.

I don't see the problem with hiring J2EE people. Same applies to J2SE. When
one hires "a" developer (any technology), is it to develop a fat or rich
client, write a socket server, write database client app, write a crypto
application, etc ? In the Java world, all these technologies are available
in J2SE. They aim of J2EE is to gather those that makes sense to put
together and have the industry implement products. OK, it sounds marketing
stuff, but "cramming all that stuff into J2EE" is also a biased comment,
isn't it...

 

[Bryce]

The problem with cramming all that stuff into J2EE is: If a potential
employer wants J2EE skills, what does he really want? JDBC? EJBs?
Servlets? JSPs? JNDI? SOAP?

My experience has been most employers are very specific on their J2EE
skills. Specially when a particular app server experience is desired.

 

[Sudsy]

On 14 Oct 2004 18:09:42 +0200, Tor Iver Wilhelmsen
<[email protected]> wrote:


My experience has been most employers are very specific on their J2EE
skills. Specially when a particular app server experience is desired.

You mean like when they ask for 5 years experience with WebLogic?
And the product has been available for...how long?
Truth be told, experience on one of the major J2EE servers should
suffice. Knowledge of the underlying concepts is transferrable.

 

[Bryce]

You mean like when they ask for 5 years experience with WebLogic?

Yep. They ask for experience with a specific app server. I've tried to
explain to recruiters that experience with one of the major J2EE
servers should carry over, they don't understand.

And the product has been available for...how long?
Truth be told, experience on one of the major J2EE servers should
suffice. Knowledge of the underlying concepts is transferrable.

But some drone in HR doesn't know that. The sheet in front of them
says "WebLogic" and if the resume in front doesn't say that, it goes
in the "no" pile (trashcan)

 

[Greg Smith]

Am I alone in this?

It surely does seem that i am alone. and i'm taking heat for it at the
office. but let me offer this question to you, how do you execute a
logical OR in struts taglib? Say, if x is empty or y is empty? i came
up with

<logic:empty name="x">
do something
</logic:empty>
<logic:notEmpty name="x">
<logic:empty name="y">
do something (the same as above)
</logic:empty>
</logic:notEmpty>

i dont think this is as elegant a solution as
<% if (x.size()==0 || y.size()==0) { %>
do something
<%}%>

especially when in the struts example we have to copy the <do
something> code twice.

alternatively, if you are mixing JSTL and XSL how do you say <x:if> OR
<c:if> in taglib language? The following resolves to logical AND:
<x:if condition>
<c:if condition>
do something
</c:if>
</x:if>

i'm willing to expose my ignorance on this one. in general i find that
the control structures offered by taglibs are less capable than what
we have in java. is there anyone who can answer the puzzle i've posed
in a more succinct manner, using taglib language?

 

[Donald Roby]

Weblogic did exist 5 years ago. Since it was then at version 4-something,
I suspect it had already been around awhile.

Yep. They ask for experience with a specific app server. I've tried to
explain to recruiters that experience with one of the major J2EE servers
should carry over, they don't understand.

The recruiter isn't the person that needs to understand that. The hiring
manager should understand that and communicate his level of flexibility
with the recruiter.

But some drone in HR doesn't know that. The sheet in front of them says
"WebLogic" and if the resume in front doesn't say that, it goes in the
"no" pile (trashcan)

Having some friends in HR, I'd prefer they weren't referred to as drones.

In the present context, the HR person's *job* is to provide a filtering
service to the hiring manager, according to rules specified by the hiring
manager on that sheet. Your "drone" is doing his job correctly.

If a hiring manager writes that sheet requiring Weblogic-specific
experience, then there are a couple possibilities:

1) He/she doesn't understand the carryover of concepts cited above. 2)
There's a good reason. This might be simply to reduce the height of the
resume pile, or the application may as currently coded depend heavily on
the server-specific implementation.

Making these decisions is the hiring manager's job.

If you think someone is an idiot for specifying these requirements, then
you don't want to work for them, so why should you care if they filter out
your resume?

If I am a hiring manager, I will certainly not specify a specific server
experience as a requirement, but might well specify a preference, and a
limit to the size of the pile HR forwards to me, which would have the same
effect.

 

[Sudsy]

It surely does seem that i am alone. and i'm taking heat for it at the
office. but let me offer this question to you, how do you execute a
logical OR in struts taglib? Say, if x is empty or y is empty? i came
up with

<logic:empty name="x">
do something
</logic:empty>
<logic:notEmpty name="x">
<logic:empty name="y">
do something (the same as above)
</logic:empty>
</logic:notEmpty>

i dont think this is as elegant a solution as
<% if (x.size()==0 || y.size()==0) { %>
do something
<%}%>

Granted, tags don't <em>generally</em> do a good job of handling
complex logic. Then again, most applications only require basic
control flow.
It seems that you're digging in your heels and trying to come up
with specific examples where scriptlet code looks more "elegant".
You're ignoring the fact that when you have a division of labour
and the HTML coders are not Java programmers then you don't want
to "pollute" the HTML with Java. It's as simple as that.
One should always choose their battles carefully. In this case,
you might want to just go with the flow and accept the standard
approach. Everyone will be happier for it.

 

[Greg Smith]

complex logic. Then again, most applications only require basic
control flow.
It seems that you're digging in your heels and trying to come up
with specific examples where scriptlet code looks more "elegant".
You're ignoring the fact that when you have a division of labour
and the HTML coders are not Java programmers then you don't want
to "pollute" the HTML with Java. It's as simple as that.
One should always choose their battles carefully. In this case,
you might want to just go with the flow and accept the standard
approach. Everyone will be happier for it.

i've only worked on projects where HTML comes from HTML designers and
programmers insert logic. i've never seen a page with logic worked on
by a designer. maybe thats why i dont see the advantage to working
exclusively with tags.

i'm not really "digging in my heels" - rather my "spidey sense" is
tingling when i see something like the "OR" example that is not easily
defined. after all, OR is a fairly simple construct (try XOR).
secondly, i see multiple implementations of IF statements among
differing taglibs. this also sets my "spidey sense" tingling. why isnt
<c:if> sufficient? why is there also a <x:if>? in contrast, we have no
need to redefine the if() conditional in java just because we add a
new class. doesnt that set your "spidey sense" tingling too?

as for choosing my battles carefully, and going with the flow, thats
not ever been my style. no doubt taglibs are the preferred method of
building jsps. i have no problem using taglibs that extend the
capability of JSP. i'm not proposing abolishing taglibs. what i am
saying is that we should be using Java for control structures - its
what Java is good at. clearly if my employer requires the exclusive
use of taglibs, i'm able to do it, willingly.

i dont really feel like a heritic. i just dont get the whole premise
that Java in the JSP is a bad thing. and since we continually reinvent
control structures for each new taglib, it seems we have a flawed
paradigm.

 

[Greg Smith]

The problem with java scriptlets and declarations in JSP is that it is
considered to make the source more difficult to read, non-XML and it opens
the door to the fanciest thing a developer can code.

As it is considered bad practice to code in a JSP, the JSP spec has evolved
to make the source an XML file and taglibs have appeared to make the java
code disappear from the JSP.

There is actually a need for tests and iterations in JSP, hence the need for
the corresponding taglibs.

Is it an "offense" to the language that taglibs have gone to the JCP and
have been intregrated in J2EE ? I don't think so, because the embracement by
the community of developers and the recognition of the existence of this
need by the JCP is the sign that there is a place for it.

OTOH, it's always possible to abuse things. And like it is possible to abuse
JSP by placing much java logic in it, it is possible to abuse taglibs.

Ben.

ben,

this is a most reasoned and level response, which i appreciate. surely
not all the responses i've received on this topic (mostly outside this
group) have been so. i have posted other responses extending my
position. as i have said elsewhere, i'm not against tags, just the use
of control structures in tags.

alternatively, if JSTL could be defined in such a way that we'd never
see another set of control structures in taglibs, i'd be happy.
although it might be more cumbersome than programming in Java, it
would at least be the last time i would have to relearn control
structures in JSP.

greg

 

[Sudsy]

Greg Smith wrote:

as for choosing my battles carefully, and going with the flow, thats
not ever been my style. no doubt taglibs are the preferred method of
building jsps. i have no problem using taglibs that extend the
capability of JSP. i'm not proposing abolishing taglibs. what i am
saying is that we should be using Java for control structures - its
what Java is good at. clearly if my employer requires the exclusive
use of taglibs, i'm able to do it, willingly.

i dont really feel like a heritic. i just dont get the whole premise
that Java in the JSP is a bad thing. and since we continually reinvent
control structures for each new taglib, it seems we have a flawed
paradigm.

I guess it comes down to how you design the application. I'm not trying
to dodge anything here, merely noting that if you have complex logic to
execute then it properly belongs in the servlet, not the JSP.
As I mentioned previously, JSP is all about presentation. About the only
logic I generally incorporate involves checking for roles or errors and
displaying accordingly.
Remember that the servlet has the choice as to which page to forward to;
don't try to make a single page suffice for all situations when you can
instead have multiple processing paths. Such an approach would obviate
the need for complex logic processing at the page level, don't you think?