Is having tags inside a jstl tag considered bad form? So for example I know the following will work but is it considered bad form to have the script tags inside my jstl tags in my jsp ?

<c:choose>
  <c:when test="${!empty bean.value}">
    <p>Its not empty</p>
  </c:when>
  <c:otherwise>
    **<script>
        callJSSomeFunction();
    </script>**
  </c:otherwise>
</c:choose>

Is having tags inside a jstl tag considered bad form? So for example I know the following will work but is it considered bad form to have the script tags inside my jstl tags in my jsp ?

<c:choose>
  <c:when test="${!empty bean.value}">
    <p>Its not empty</p>
  </c:when>
  <c:otherwise>
    **<script>
        callJSSomeFunction();
    </script>**
  </c:otherwise>
</c:choose>

• javascript
• jsp
• jstl

3 Answers 3

I don't know about bad form (a bit harsh) but you might consider that to someone viewing your page without JS enabled your <c:otherwise> will effectively output nothing, and that's not very graceful.

Also, if the page is rendered incrementally your function call might execute as it has been ouput, and before the DOM has been fully loaded by the browser and thus behave unpredictably (or just not work at all - I've had this happen).

I would consider putting all function invocations in the head, and use one of the many available tricks for detecting when the DOM has loaded (jQuery's $(document).ready() for example) to enforce a neater separation, and make your life that much easier.

I don't think so - this is how you conditionally do things in JSTL, I don't think you should have a script tag just to have one.

I'm dealing with some big giant JSTL terds in the punchbowl right now so I thought I'd throw some UI dev perspective into the mix.

SGM-like syntax wrapping another domain of SGM-like syntax is awful form, generally but that's not your fault. You can help make it better by keeping them separated however. This isn't always possible, but the more you can set vars and drop them into HTML only where necessary, the better.

The other problem is that you're trying to set off client-side scripts directly with server-side code and I would say yes, given my five years of experience handling UI code, that it is a big giant PITA for your UI folks to suddenly run into triggers they don't really know how to follow back to the origin and don't have any control over. Hell, triggers that even Java devs aren't necessarily sure how to follow back to the origin if things are ugly enough.

Imagine being in our shoes. Take a service driven architecture but let us add Java strings into the param mix that let us actually establish object method calls from the client-side. Is that a good idea? No, it's a horrible idea. Not because you don't want JavaScript devs writing Java (you don't - it makes us really unpleasant) but because at those two points of separation things should be as simple as possible. I send you data, you can deal with it however you want.

So just hand us data already. Ideally in JSON form but we'll put up with anything to keep JS execution from being determined by the server. The last thing you want is a stampede of UI hooves in your OOP-murdering-bean-filled pastures so don't force us to e looking for what the crap got tightly bound between points on either side of the HTTP wall for no reason that ever made good sense to me. We wrap messages around rocks and chuck 'em over the wall. That sounds inelegant but no "thin-client" solution in my experience has ever caused less pain.

Trust your "ick" instincts. Sometimes they're wrong but you should figure this out in the shower in the morning when you're still thinking about it because usually they're right.