I was actually using a build from a few weeks ago, one of the first 1.2
builds. Just updated my SVN and yes, now I see this code in
UIXCommand. Sorry, should've checked first.
Unfortunately now the build isn't working for trinidad-impl ... it seems
the Maven plugin is producing a bunch of files (Tag classes like
ConvertDateTimeTag, ConvertNumberTag, ValidateDateTimeTag) that want to
use TagUtils.getValueBinding, TagUtils.isValueReference, etc., and can't
find them. Maybe those methods in TagUtils got nuked during the last
merge with trunk?
Using Facelets FWIW.
Adam Winer wrote:
> Here's the code I see in UIXCommand.getAction():
>
> public MethodBinding getAction()
> {
> MethodExpression me = getActionExpression();
> if (me == null)
> return null;
>
> if (me instanceof MethodBindingMethodExpression)
> return ((MethodBindingMethodExpression) me).getMethodBinding();
>
> return new MethodExpressionMethodBinding(me);
> }
>
> Where did you see the code you're reporting here?!?
>
> Dunno why the RI is calling getAction() - it should, for any component
> that implements ActionSource2, call getActionExpression(). But that's
> 99.9% besides the point.
>
> I assume that the real issue is that getActionExpression() is
> returning null.
> BTW, are you using JSPs or Facelets?
>
> -- Adam
>
>
>
> On 10/29/06, Rogers Reilly <rogers_reilly@s-rod.com> wrote:
>
>> Hi,
>>
>> I'm having trouble using <tr:commandButton />s in conjunction with
>> regular JSF navigation rules in the 1.2 branch. Any click on these
>> buttons does submit the form, but the server's response is always the
>> same view, and the method bound to "action" is never called. Identical
>> code using <h:commandButton /> works as expected.
>>
>> I've done some debugging, and it seems the problem is with
>> UIXCommand.getAction():
>>
>> public MethodBinding getAction()
>> {
>> MethodExpression me = getActionExpression();
>> return null;
>> }
>>
>> When ApplicationListenerImpl (of the RI) gets null for the action
>> binding, it passes this to the NavigationHandler, which then just
>> returns the current view.
>>
>> I would say the fix as simple as returning the "me" MethodExpression,
>> but Eclipse is telling me that "me" is evaluating to null, so it may be
>> that something deeper in .getActionExpression() needs fixing too.
>>
>> It does seem that .getAction is supposed to be deprecated (replaced with
>> .getActionExpression), but as the 1.2 RI is calling is, I'm assuming it
>> needs to be implemented.
>>
>> Rogers
>>
>>
>
>
|