> Sorry to read about your pain, but I actually prefer the new
> code! I don't
> have to remember what are no worse than proprietary tags and
> their syntax,
> and can easily write code that is going to be infinitely more
> flexible than
> LOOP and INCLUDEIF and EXCLUDEIF can be. And if you align
> the code like you
> have in your first example, it doesn't look that terrible:
I agree that lack of flexibility of LOOP, INCLUDEIF and EXCLUDEIF was
definitely a problem in 0.92 (what, no non-LOOP tags in a LOOP?
Made it really hard to do a selected option without yet another
scriptlet. And no obvious way to compare one property to another made
INCLUDEIF and EXCLUDEIF far less useful than they could have been.)
On the other hand, one of the stated aims of JSP was to separate
presentation from content, in order to allow HTML people
(non-programmers by assumption) to do the presentation while
the programmers create the content.
Now, in this rather illustrative example:
> <TABLE>
> <% RowBean[] rows = results.getRows();
> for (int i = 0; i < rows.length; i++) { %>
> <TR>
> <% CellBean[] cells = rows[i].getCells();
> for (int j = 0; j < cells.length; j++) { %>
> <TD><%= cells[j] %></TD>
> <% } %>
> </TR>
> <% } %>
> </TABLE>
we find the content horribly intermingled with the presentation
again. Two roles have to collaborate to produce this particular
JSP code - a programmer who can write correct scriptlets, and an
HTML designer who develops the HTML presentation code. Ugh!!!
This is a major step backwards. Separation of these roles is
rather crucial if you have a significant size of project or of
project team. Standard software development management practice
will tell you to reduce these sorts of interactions amongst team
members where possible rather than mandate them. It also mandates
that you break the entire development task up into units which can
be completed by people with differing skill sets and levels. The
code above does not enable that partition.
> There are formatting beans out there if you want to move the
> code generation
> into a formatting bean. I believe IBM has a number of them.
> Or you could
> easily write a bean to produce your output.
Ugh. That again intermingles the roles, and takes away a large chunk
of the value proposition of JSP, but perhaps not as badly as the
previous example. Some programmer builds a bean to write HTML output.
Then you teach your HTML developer to not use the HTML they are already
familiar with, but to use the pre-programmed functionality in another bean.
I can't imagine they're going to like that too much, especially when they
have less control over the bean (and any bugs it has) compared to doing it
in HTML themselves.
Cheers,
Richard.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
