On 1/5/06, Laurie Harper <[EMAIL PROTECTED]> wrote:
>
> Thanks to my unusual use of view identifiers carrying path-extra-info
> information, I've discovered a bit of a limitation with
> DefaultViewControllerMapper: if the result of applying the mapping
> algorithm isn't legal as a value binding expression, you get an ugly
> stack trace. I triggered this because I have view identifiers which may
> include spaces or other 'special' characters which, to be fair, the
> Javadoc explicitly states you shouldn't do :-)
There are some alternative ways to code a VB expression that might deal with
some of these issues. It centers around the fact that, in EL expressions
(as in JavaScript), the following two expressions do the same thing:
foo.bar
foo['bar']
so if the "bar" part of your expression has characters that would mess you
up ... a period is the most common one that I've run into ... use the latter
syntax. This is paticularly handy, for example, when using <f:loadBundle>,
where the message keys in your properties file have periods in them:
<f:loadBundle name="messages" bundleName="com.mycompany.MyBundle"/>
...
<h:outputLabel ... value="#{messages['username.label']}" .../>
Looking at the bigger picture, any mapper implementation that's not
> well-behaved (in terms of returning a value that can be turned into a
> value binding) is going to cause this behavior.
>
> I thought it'd be a simple case of catching the exception when the value
> binding expression is created (ReferenceSyntaxException from
> createValueBinding() or EvaluationException from getValue()), but it
> looks like the EL implementation I'm using (from Facelets) is throwing
> an implementation exception rather than the correct, documented
> exception -- I'm getting a com.sun.faces.el.impl.ElException from
> createValueBinding() (using the RI).
>
> Is there any clean way to deal with this, since catching
> com.sun.faces.el.impl.ElException in Shale isn't really appropriate...
See above.
L.
Craig
