I work in a shop similar to the one you describe where individuals are
forced to fill multiple roles. I'm called upon to implement everything
from domain models to navigation menus. However, I find that keeping
the Java code that appears in JSP to a minimum helps in this situation
as well. Although I am completely capable of wearing multiple hats, I
do feel that we all benefit from practices that limit the amount of time
we have to wear all those hats at once. I would also argue the quality
of our work benefits from the increased level of focus such discipline
provides. Some logic does belong in JSP. However, the logic that
appears within pages should be limited to display logic. I've found
that Struts and JSTL are a great combination to accomplish such
separation.
-Sean
On Sun, 2005-01-23 at 10:45 -0500, Frank W. Zammetti wrote:
> I certainly wouldn't presume to speak for Craig, so this is just my own
> answer...
>
> Scriplets, that is, code in JSPs inside <% %>, is generally considered a
> Bad Thing(tm) because it's too easy for business logic to sneak into the
> presentation.
>
> Now, there is I think room for debate about how far to push that idea.
> Some people think that a JSP should be absolutely nothing more than a
> template for display, so you should wind up with nothing but things like
> <$=someVar%>, or more "correctly", something like <bean:write
> name="myBean" property="myVar" />.
>
> However, where there is room for debate is whether using any sort of
> logic whatsoever in a JSP is bad or not. Taking the "JSP as a template
> only" idea to it's fullest extent seems to me to imply that logic in ANY
> form is to be avoided, and should not be done in a JSP, whether it's
> using taglibs or not to do it (i.e., <logic:equal/> shouldn't even be
> used because it's logic). I think this is too extreme and limits the
> types of applications you can do... try doing the kinds of apps I do for
> a living for example, which are webapps that look, feel and work like
> fat clients, and you'll be hard-pressed to pull off the kinds of things
> I do without some level of logic in JSPs.
>
> That being said, good design dictates that you need to be careful what
> gets put in your JSPs, whether you use custom tags or not (I'm not a fan
> of custom tags myself in most cases). Business logic does NOT belong in
> JSPs, and indeed anything other than trivial bits of code probably
> shouldn't be there either.
>
> I'm not entirely sure what the code you posted is doing, but my gut
> feeling is that it's too much for a JSP. I do things like this all the
> time;
>
> <%
> boolean altRow = false;
> String rowStyle = "";
> for (Iterator it = form.getTOAList().iterator(); it.hasNext(); ) {
> if (altRow) {
> rowStyle = "cssListboxAltRow";
> altRow = false;
> } else {
> rowStyle = "";
> altRow = true;
> }
> HashMap nextItem = (HashMap)it.next();
> BigDecimal toaID = (BigDecimal)nextItem.get("toaID");
> String status = (String)nextItem.get("status");
> %>
> <tr height="24" class="<%=rowStyle%>">
> <td><%=status%></td>
> <td><%=toaID%></td>
> </tr>
> <%
> }
> %>
>
> ...and some will say that's way too much... let's skip the "this should
> be a custom tag!" argument for the time being... This kind of code I see
> no problem with being in a JSP. It's strictly presentation-oriented,
> and isn't extensive.
>
> That being said, NOW we can get to the "this shouldn't be there at all"
> argument... it is a perfectly reasonable argument. In an environment
> where you have page authors and Java coders, you don't want your page
> authors to have to see code like that. In fact, in the "perfect"
> environment where it's split exactly right, they wouldn't even know what
> this code meant. But, if you had a custom tag that encapsulated that
> functionality, they could just put <showTOAList/> and be done with it.
> That's the argument for taglibs (the main one anyway).
>
> However, you have to ask yourself what kind of environment your in... I
> dare say most environments are NOT set up that way... maybe they should
> be, but I don't think the majority are... most places, your page authors
> are your Java coders are your database developers are your business
> analysts, etc. In that case, I think the argument doesn't carry as much
> weight.
>
> Eh, I guess I'm off on a bit of a tangent. Most people will tell you
> that code in JSPs is to be avoided, and I'm not going out of my way to
> debate that. But, I think it's fair to say that if you do have code in
> JSPs, it should be (a) trivial and (b) strictly presentation-related.
> Breaking THOSE rules, which by extension breaks the higher rules, is to
> be avoided at all costs. Just my opinions.
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> Dola Woolfe wrote:
> > I just read this thread and didn't quite understand
> > it. If it means what it seems to mean on the surface,
> > I'm doing everything wrong.
> >
> > Schematically, my typical JSP page looks like the
> > following (basically 100% code). Is this what Craig is
> > advising against?
> >
> > <%@ page errorPage="ErrorPage.jsp" import="html.*"%>
> > <[EMAIL PROTECTED] file="InitializePage.jsp"%>
> > <%
> > Table table = new Table()
> > .pAddH("#").pAddH("Action").pLN()
> > .pAddC("1").pAddL(new Anchor("HelloPage.jsp", "Say
> > hello to my friend.")).pLN()
> > .pAddC("2").pAddL(new Anchor("GoodByePage.jsp",
> > "Say good bye to my friend")).pLN()
> > ;
> >
> > MyTemplate template = new MyTemplate ("Main
> > Actions", table);
> > Page pAgE = new Page(new MyHead("Data Tools"), new
> > Body(template));
> > %>
> >
> > <%= pAgE %>
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Read only the mail you want - Yahoo! Mail SpamGuard.
> > http://promotions.yahoo.com/new_mail
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> > .
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
