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

Discussion in 'Java' started by Greg Smith, Oct 14, 2004.

  1. Greg Smith

    Greg Smith Guest

    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

    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?
    Greg Smith, Oct 14, 2004
    1. Advertisements

  2. Greg Smith

    Ben_ Guest

    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_, Oct 14, 2004
    1. Advertisements

  3. 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.
    Tor Iver Wilhelmsen, Oct 14, 2004
  4. Greg Smith

    John Harlow Guest

    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.

    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.
    John Harlow, Oct 14, 2004
  5. Greg Smith

    Will Hartung Guest

    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.


    Will Hartung
    Will Hartung, Oct 14, 2004
  6. Greg Smith

    Will Hartung Guest

    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


    Will Hartung
    Will Hartung, Oct 14, 2004
  7. yep
    The Abrasive Sponge, Oct 14, 2004
  8. Greg Smith

    John Harlow Guest

    The problem isn't the markup language, it's simply the whole paradigm
    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.
    John Harlow, Oct 14, 2004
  9. Greg Smith

    Will Hartung Guest

    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.


    Will Hartung
    Will Hartung, Oct 15, 2004
  10. Greg Smith

    Sudsy Guest

    It's a matter of separating mark-up from content and it's the best
    approach I've seen, IMHO.
    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!
    Sudsy, Oct 15, 2004
  11. Greg Smith

    Ben_ Guest

    The problem with cramming all that stuff into J2EE is: If a potential
    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,

    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... :)
    Ben_, Oct 15, 2004
  12. Greg Smith

    Bryce Guest

    My experience has been most employers are very specific on their J2EE
    skills. Specially when a particular app server experience is desired.
    Bryce, Oct 15, 2004
  13. Greg Smith

    Sudsy Guest

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

    Bryce Guest

    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.
    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)
    Bryce, Oct 15, 2004
  15. Greg Smith

    Greg Smith Guest

    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:notEmpty name="x">
    <logic:empty name="y">
    do something (the same as above)

    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

    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?
    Greg Smith, Oct 16, 2004
  16. Greg Smith

    Donald Roby Guest

    Weblogic did exist 5 years ago. Since it was then at version 4-something,
    I suspect it had already been around awhile.
    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.
    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
    Donald Roby, Oct 16, 2004
  17. Greg Smith

    Sudsy Guest

    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.
    Sudsy, Oct 16, 2004
  18. Greg Smith

    Greg Smith Guest

    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
    Greg Smith, Oct 17, 2004
  19. Greg Smith

    Greg Smith Guest


    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 Smith, Oct 17, 2004
  20. Greg Smith

    Sudsy Guest

    Greg Smith wrote:
    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?
    Sudsy, Oct 17, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.