On 1/5/06, Laurie Harper <[EMAIL PROTECTED]> wrote:
>
> Craig McClanahan wrote:
> > 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.
>
> You're talking about either changing what's in the view ID, or changing
> how it's mapped. Both of those will fix the problem on a case-by-case
> basis, sure.
>
> What I was getting at was more, can we make it so that a 'bad' view
> controller name doesn't cause a blow-up? What I was going to propose was
> changing ShaleViewController's setupViewController() method (and other
> places which use the mapping manager) something like this:
>
> // Retrieve an existing instance, or one created and configured
> by
> // the managed bean facility
> - ValueBinding vb =
> - context.getApplication().createValueBinding("#{" + viewName
> + "}");
> ViewController vc = null;
> try {
> + ValueBinding vb =
> + context.getApplication().createValueBinding("#{" +
> viewName Object vcObject = vb.getValue(context);
> if (vcObject == null) {
> log.warn(messages.getMessage("view.noViewController",
> new Object[] { viewId,
> viewName }));
> return;
> }
> vc = (ViewController) vcObject;
> } catch (ClassCastException e) {
> log.warn(messages.getMessage("view.notViewController",
> new Object[] { viewId,
> viewName }));
> return;
> + } catch (ReferenceSyntaxException e) {
> + // ... log an error/warning and return
> + } catch (EvaluationException e) {
> + // ... log an error/warning and return
> }
>
> The rationale is that
>
> a) Shale users may plug in a naive or broken mapper; it'd be nicer to
> fail gracefully, letting them know what the problem is, rather than
> throw an exception
>
> b) Third-party component libraries may (I think?) include navigation
> rules in their bundled faces-config that point to view IDs which don't
> conform to the constraints of whatever mapper may be installed
Something like this does make sense ... let's be as explicit as we can when
we run into probems.
That being said, in this case its still something *we* (Shale) are doing, by
composing a value binding expression that might not be valid. It's also
worth figuring out if we can use an alternate syntax so that a vew
identifier like "foo.bar" would still work.
But ... wait ... its even easier than that. We should be using the
VariableResolver directly, instead of composing a value binding expression.
This won't care about the syntax, and will be a bit more efficient to boot.
I guess it could just be 'catch Exception' but that seems a little
> over-protective ;-)
+1 ... exceptions from the view controller's constructor are the user's
problem :-).
L.
Craig
