B) The expression may evaluate to an empty string
I'm not sure how this is unique to making the id attribute able to be
an expression. This is certainly true of every other attribute, and
an broken id couldn't break a JSP more than an incorrect config or
options attribute (we still need to work on error messages when
options don't resolve to a valid location). As always, the library
gives a certain amount of rope. Allowing them to make this an
expression if their design requires it doesn't mean it's the RDC's
fault if they incorrectly implement it.
C) Group DM strategies such as the RuleBasedDirectedDialog or
SCXMLDialog
probably become unusable
I really like the DM strategy support - though we're not going to be
using it most likely ourselves (so far at least).
But allowing an attribute to be an expression doesn't mean it must be
one, just that it can. If you're using an RDC group tag in the style
of the examples - probably the most common case - then you can
continue to have the id be static. But are ids as expressions and
aggregation mutually exclusive? I wonder if a careful design make
sure that ids are unique even if they're in a group of RDCs, which
might be useful if that pattern appeared over and over, with enough
differences that composition wouldn't work. Just a thought. In any
case, I guess my main point is that I don't see how allowing the id
to be an expression harms ability to use RDCs in groups.
Particularly with a spiffy wiki page explaining what to look out for.
Stu
On Aug 3, 2005, at 10:34 PM, Rahul P Akolkar wrote:
Stu Robertson <[EMAIL PROTECTED]> wrote on 08/03/2005 11:19:07 PM:
The id attribute of the RDCs does not allow the value to be set via
an expression, unlike all other attributes I've found.
We're implementing our applications using the simplest possible
pattern, where each JSP contains a single RDC. So the JSPs
themselves are identical for a given type of RDC. We have quite a
few selectOne tags in an average application. The bits that vary
between page, in our design, are populated by expressions, getting
their values from state stored in the session.
The only one causing trouble is the id. I've made the changes to the
RDCs we're using, and will be working though any kinks tomorrow. I
just wanted to find out if there was a particular reason why this
constraint was added, and so maybe anticipate issues with other
plumbing bits.
The ID of an RDC is really meant to be an XML ID, unique to the
document.
While in your use case, I understand that this will be clean,
opening up
the IDs completely such that they can be expressions probably opens
a can
of worms:
A) It becomes harder to determine if there are duplicate IDs
B) The expression may evaluate to an empty string
C) Group DM strategies such as the RuleBasedDirectedDialog or
SCXMLDialog
probably become unusable
It might be worthwhile brainstorming approaches for the "page level
templating" that you mention above. I can't think of an elegant
solution
off-hand.
Thanks,
Stu
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
