Hi Ture,
Ture Hoefner wrote:
>Thanks Rich. I went with PageFlowUtils.addActionErrorExpression(). I
>also used the tip that Eddie gave in another thread for building a JSP
>2.0 EL expression for a message key that uses dot notation in the key
>like this:
>
>"${bundle.myBundleName['my.msg.key']}"
>
>By the way, I had seen the PageFlowUtils.addActionErrorExpression()
>method in the javadoc before but did not try it because I didn't
>understand that the String expression arg was used as the JSP 2.0 EL
>expression for the bundleName in the <netui:error> tag that is
>displaying the error message from this method call. Maybe a link to the
>javadoc for the bundleName element of the Jpf.MessageBundle annotation
>would help? And maybe some extra text to explain that the "expression
>is used as an EL expression to
>databind a named message bundle in JSPs that display the action
>error"... or something like that?
>
>
I noticed the JavaDoc weakness for the 'expression' parameter, too --
I've updated it to be more descriptive. The only thing I wanted to add,
though, is that there is no direct link between message bundles and the
expression you add. Whatever expression you use will be evaluated as
the error mesage. I think what you're doing (with the 'bundle' binding
context ) is exactly right, but I was confused by the comment about
bundleName.
>Thanks for the help....it would have taken me forever to figure it out
>on my own.
>
>
Means we need to add some good doc in this area. :)
Rich
>Ture
>
>
>-----Original Message-----
>From: Rich Feit [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, November 08, 2005 9:34 PM
>To: Beehive Users
>Subject: Re: PageflowUtils.addActionError() and non-default message
>bundle
>
>Hi Ture,
>
>I think you have two options currently:
>
> - PageFlowUtils.addActionErrorExpression(request, "someProperty",
>"${bundle.someOtherBundle.myMessage}", <args>)
> - use the 'bundleName' attribute on <netui:error>
>
>Would either of these work for you?
>
>Rich
>
>p.s. var-args would be nice, huh? Currently, the NetUI code doesn't use
>Java 5 features internally, because there's a layer that lets it run
>under 1.4 (with XDoclet-style annotations). This never really became a
>supported feature, and the no-Java5 restriction will end at some point.
>
>
>
>
>