Jakarta Pitfalls: Cactus & JUnit Testing, Struts TagLibs & JSPs

Discussions

News: Jakarta Pitfalls: Cactus & JUnit Testing, Struts TagLibs & JSPs

  1. Two chapter excerpts from Wiley's 'Jakarta Pitfalls' have been made available for download. The Cactus and JUnit chapter examines pitfalls when building a test set with these tools such as 'Unreasonable Assert', 'Console-Based Testing' and others. The Struts TagLibs and JSPs chapter looks at pitfalls such as 'Performing Business Logic in JSPs' and 'Hard-coded keys in JSPs'.

    Download Testing: Cactus and JUnit and Struts TagLibs and JSPs

    Threaded Messages (31)

  2. Another Struts pitfall[ Go to top ]

    I have another Struts pitfall here: Do not use the Struts logic tags. In fact they don't reduce the logic in the JSPs, rather they introduce a new (very limited) programming language.
  3. Another Struts pitfall[ Go to top ]

    how do you propose doing iterations without the logic tag?
  4. Another Struts pitfall[ Go to top ]

    JSTL
  5. Another Struts pitfall[ Go to top ]

    I think the authors touched on this point in the "Business Rules in JSP" pitfall, but the only example they gave (mis)used scriptlets. It would be nice if they made it clear that you can also implement business rules using custom tag logic (Struts logic tags or JSTL), and this is just as bad or worse than scriptlets.
  6. JSLT[ Go to top ]

    I agree. The JSLT tags are designed to be more industry standard and can be used away from Struts (if you wish!)
  7. JSP pitfall[ Go to top ]

    I might not be very original, but I would say JSP is the pitfall here. To get clean view code, I use Velocity/ Freemarker/ Webmacro. I have used JSP's for several projects as well, with several combinations of taglibs, but never got the views as nice and clean as with a template engine.
  8. JSP pitfall[ Go to top ]

    We used JSTL with JSP in our latest projects and our views are clean and lean, without a bit of business logic. I realy don't see how a template engine (Velocity/FreeMaker/WebMacro) can produce cleaner and leaner view then JSP/JSTL when JSP is itself a template engine (although one that does not interpret but compile and although one that is bound to servlet API).
    You can mess up things with template engine too if you want. Velocity also has contidional and iterational commands, I dont know about other templete engine mentioned.

    Mileta
  9. From userguide (Struts)

    Note: - Many of the features in this taglib are also available in the JavaServer Pages Standard Tag Library (JSTL). The Struts team encourages the use of the standard tags over the Struts specific tags when possible.

    (http://jakarta.apache.org/struts/userGuide/dev_logic.html)

    // Torben
  10. Another Struts pitfall[ Go to top ]

    what tag in JSTL for logic:iterate ?
  11. tag in JSTL for logic:iterate[ Go to top ]

    c:forEach
  12. I agree[ Go to top ]

    I agree.
    Why throw away year of research in designing if, for and while?
    Trying to do these things with tags is painful.
  13. Poor example of pitfalls[ Go to top ]

    Most of those examples don't show fault of Struts but fault of poor coding/design. It sounds like the author is saying that because you *can* do this poor coding practices then Struts and its taglibs are bad. I sure would hope that everyone agrees that performing business logic in the JSP's is bad.... this isn't any fault of StrutsTaglibs it's the fault of the developer.

    Earily someone mention to use Velocity, OK, I agree, but I'm sure somebody can write just as bad velocity code so it comes back down to the developer doing the right thing, don't go blaming the tools at hand for the poor code that was created. I think Velocity is great, its fast and isn't dependant on the containers compiler (Jasper) but the arguement that velocity is cleaner then JSP is a skewwed perspective, take this from the Velocity site, http://jakarta.apache.org/velocity/casestudy1.html SURE that JSP is very bad, but who writes JSP's like that!!!! It's the developer that should get blasted not the tool!!!

    Also earily someone mention using JSTL and that too is a good approach. I have used it on a past implementation using the Maverick framework and I would say JSTL was great BUT JSTL opens up the ability for poor developers to write even worse code.

    At least the author showed a better way to fix the problem/pitfall.

    Kris Thompson
    www.frameworks-boulder.org
  14. Poor example of pitfalls[ Go to top ]

    The examples are sure enough a fault of poor design/coding, but the fact that the framework does not restrict the developer from using such bad designs is sure enough a pitfall of the framework. IMHO a good framework is that which restricts bad design and promotes good design, and a perfect example of that in this realm would be Tapestry!
  15. Poor example of pitfalls[ Go to top ]

    Good gravey, put me in a straight jacket so that I don't hurt myself with my code. Folks, take some resposibility for the code you write. In the book "The Pragmatic Programmer" Dave Thomas states it well in the first chapter to do just that. Sure JSTL has the sql tag but don't use it! I don't know Tapestry and it might prevent you from hurting yourself and that is fine (I have heard good plenty of good things about Tapestry) but don't fault the framework/tool... otherwise there are A LOT of tools out there that have "pitfalls".
  16. Poor example of pitfalls[ Go to top ]

    Don't get me wrong, I agree that developers should take responsibility and would like to see good code coming from every one of them, but that's just not going to happen until it is shoved down the throat! Books like these are going to help the disciplined but for the rest its like traffic rules with no cops on the road!
  17. Poor example of pitfalls[ Go to top ]

    Don't get me wrong, I agree that developers should take responsibility and would like to see good code coming from every one of them, but that's just not going to happen until it is shoved down the throat! Books like these are going to help the disciplined but for the rest its like traffic rules with no cops on the road!

    I would argue that books like this will help those who want to improve. There isn't much we can do for those who don't care - even shoving something down their throat won't work.
  18. Poor example of pitfalls[ Go to top ]

    Most of those examples don't show fault of Struts but fault of poor coding/design. It sounds like the author is saying that because you *can* do this poor coding practices then Struts and its taglibs are bad.

    I think you have misinterpreted the author's intent here. He is not blaming Struts, but trying to point out common mistakes. Regardless of what tool or technology you use, there will be common misuses and traps to avoid. Whether you agree with the author's documented pitfalls or not, this (at least to me) is clearly what they intended to do. I would like to see more of these types of books, because the majority of developers out there are still making these kinds of mistakes every day.

    As a side note, this book covers a number of things other than Struts pitfalls. One could get the impression that most of the book is about Struts based on the conversation here, but the book covers other commonly used jakarta stuff as well.

    Check the book out. I think it is worth the read.
  19. Poor example of pitfalls[ Go to top ]

    Sorry for the misunderstanding, I am targeting in on just one small piece of the book and I too would agree that this is a wonderful read as a How-not-to. I will give it better look over.
  20. Poor example of pitfalls[ Go to top ]

    JSTL allows developers to use SQL in JSP's
    Usually this is a very bad practise, but what about a simple stupid application, would you do the three tiers?

    JSTL is as bad as the developer who uses it
  21. Poor Programming = Pitfalls[ Go to top ]

    Hi alegria,

    > JSTL allows developers to use SQL in JSP's
    > Usually this is a very bad practise, but what about a simple stupid application, would you do the three tiers?
    >
    > JSTL is as bad as the developer who uses it

    This is exactly the point of the book. Not that developers are bad but that inexperienced developers make bad choices because of many reasons. Once these bad choices are made their code is 'stuck' in the pitfall. The book gives concrete examples of these 'stuck' spots and how to get out of them.

    There is nothing (or very little) on JSTL because the book focuses on Struts (and Ant & Cactus). But you are correct that putting SQL tags into your JSP is bad form. In fact that is documented in the J2EE AntiPatterns book that I also co-authored in the JSP chapter.

    The form of the AntiPatterns book is much more formal but basically has the same feel. It presents something that we or someone we know has done wrong in building a J2EE app and then gives concrete means through refactorings on how to make it better.

    You can get some sample chapters from that book at Patterns Central @

    http://www.patternscentral.com/modules.php?name=Downloads&d_op=viewdownload&cid=7#categorystart

    There was also a short thread on the AntiPatterns book here at Server Side;

    http://www.theserverside.com//home/thread.jsp?thread_id=20703&article_count=4

    Thanks for the feedback!

    TTFN,

    -bd-
  22. Don't be in panic !

    I love anti-patterns books and pitfalls tips. This permit to answer real-world common questions and is useful to avoid common errors.
    Thus, the idea to write a new book about Jakarta common frameworks used in web development appears to be very good.

    But it seems the authors of this book need to buy tons of papers; some of the pitfalls are so unuseful, most are just part of the Struts Tutorial, some are even bad ideas.

    Examples ?


    Chapter 4 / Pitfall 4.2 : Hard-Coded Keys in JSPs

    <quote>
    This usually turns into a maintenance hassle over time.
    Suppose for example that the initial naming scheme for properties is outgrown,
    and a new naming scheme is introduced. The new naming scheme
    will require the old properties to be renamed. Searching through each JSP
    looking for each instance of the old property name becomes very tedious
    very quickly.
    </quote>

    Who met this kind of problem ?
    Oh, sorry. Some projects are evolving and there may be a new naming scheme to be introduced.
    Better: Who met this kind of problem without thinking 'oups, we may have a 1-hour think before coding' ?

    So, what is the solution ?
    Easy, use Java Classes to declare Constants. And getting more and more 'hard_dependencies' over many files. As struts do. (i love struts, but i really think that 'hard-coupling' of the too many files - jsp, properties, request attributes, validator classes, model,...- decreases productivity ).

    Is it really an advantage to add development work (declaring a pivot java file with constants) when each declared constant is used as an alias (one to one) ??? Please let me doubt.
    Then, adding import of the java class, then declaring the usebean, then replacing the scriptlet with expression.



    Next example:

    Chapter 4 / Pitfall 4.5: Performing Business Logic in JSPs

    This pitfall is mismatching the subject : it would be 'centralize reused display logic into helper classes rather than in JSPs'.
    In fact, this pitfall is only necessary for REUSED display logic !


    Some other pitfalls are just Struts-features presentation. Nice to re-read (i18n strings, options, token).


    Yann
    Scriptlet is evil but, look around you, we have to live with evil ! So let's live with scriptlets. Just use them moderately ;-)
  23. Another step-by-step cookbook?[ Go to top ]

    It is nice to have a reference book which gathered under one cover a lot of well-known programming techniques (don't want to use the "p" word). But sometimes it pays off to think out of the box. Innovations are often made by dilettantes.
  24. what is keysToSkip()?[ Go to top ]

    In page 217 of chap4, it states to override the keysToSkip() method in the InvoiceForm class. Is this a struts feature? I cannot find any clue on this anywhere.

    Thanks!

    ct
  25. what is keysToSkip()?[ Go to top ]

    Hi ct,

    keysToSkip is introduced in Chapter 3.

    You can download the code for the book at
    Wiley Book Site
    under the Chapters 2,3,4 link.

    TTFN,

    -bd-
  26. Wrong location for ".properties" file[ Go to top ]

    This doesn't quite seem the right place to note ordinary content issues, but I don't see any other place to do this.

    In the "Struts/JSP" excerpt, on page 201, in the description of "Create a .properties file", it says this:

    Place the .properties file somewhere in the path at runtime. It is
    typical to place the .properties file alongside the struts-config.xml
    file in the WAR file.

    This has some problems. First of all, referring to the "path" is wrong, as it's technically the CLASSPATH. Second, the "WEB-INF" directory, where the "struts-config.xml" file goes, is not in the CLASSPATH. The ".properties" file normally goes in the "WEB-INF/classes" directory, in the directory corresponding to the package of the resource bundle (which could be the "default" package).
  27. Wrong location for ".properties" file[ Go to top ]

    David,

    Thanks for pointing this out. You're absolutely right, and of course all of our example code reflects that, as the ApplicationResources.properties file can be found under WEB-INF/classes in each example solution.

    I confess to having pulled several all-nighters in the process of meeting the book's rather tight publication deadlines, and I can only imagine having written this atrocious sentence around say, four or five AM. ;-) Unfortunately, neither of the book's otherwise excellent technical reviewers happened to catch it. You can be sure I'll be adding it to the Errata compilation though. Thanks for your feedback!

    Jonathan
  28. Question regarding the Constants class[ Go to top ]

    First let me start by saying I haven't taken the time to download, compile and run the samples, so I could be wrong, but since the class Constant is declared as abstract, wouldn't it's use with the EL be impossible since an instance would need to be created to call the methods? Normally the compiler catches any attempts to create an instance, but what happens at run-time since we're circumventing the compiler in this case?
  29. Constant class generator[ Go to top ]

    I believe the Constants class is a decent idea, but what I really like though is it's use with the EL because the syntax is really clean looking. It inspired me to search the net for either some utility or Ant task that takes a properties file and generates the Constants class for you. I had no luck finding such a 'standalone' utility, but I have seen it in some IDE's.

    Anyone know of such a constant class generator utility that's not tied to any IDE?

    Alex
  30. Constant class generator[ Go to top ]

    Hi Alex,

    The idea of using code generation to make the constants class is a good one. XDoclet is probaly the place to start (xdoclet.sf.net). I don't see anything that directly does what you suggest but extending XDoclet is supposed to be a snap (although I have not personally done it).

    I'm looking into the Constants class but I susspect that your observation is correct and we have another bit of errata.

    Best of luck and thanks for the feedback!

    TTFN,

    -bd-
  31. Shouldn't JSP source reference struts-el?[ Go to top ]

    Shouldn't the JSP examples using the EL also be using the struts-el taglib? The source makes it look like the EL works by default with the struts tags.
  32. Shouldn't JSP source reference struts-el?[ Go to top ]

    BTW, I'm referring to the sample source on page 208 of the PDF that's available for download