On Sep 10, 2005, at 3:58 PM, Robert Zeigler wrote:
Hm... I agree with Howard on this one...
Suppose you had put:
<select jwcid="@PropertySelection" ... class="ognl:htmlClass"/>
Would you want tapestry to print out:
<select ... class="ognl:htmlClass"/>, or would you want tapestry to
print out the result returned by evaluating htmlClass?
I would want the former actually. It would let me know right away
that I had done something wrong. I think this was actually how it
worked in T3 too. I recall having typed "listeners" instead of
"listener" once and I did not get back an error about an invalid ognl
property; the text just passed through to the output. Viewing the
HTML and seeing the passed through informal parameter, I was able to
figure out why my listener wasn't being called. Maybe my memory
about this is just hazy though.
It's the same concept, albeit slightly obfuscated by the fact
that we /do/ have listeners, and listeners normally don't cause
anything
to be printed in the html. Be that as it may, since it's an informal
parameter, the expectation on tapestry's part is that you want a
string
printed. It's entirely consistent, and the message is equally
equivalent with:
class="ognl:dynamicClass" throwing a "property not found" exception if
getDynamicClass can't be found.
Okay, I think I finally get what you guys were saying, although I had
to use a test case to illustrate. I didn't realize then when I did
provide the listener method that it was passing through a String
representation of that method. Apologies for making so much noise.
I guess I was expecting something that would be more helpful to say
"hey, using a listener method here doesn't make sense". Now I see
how it works though.
--
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
