Madhav,
Well, people here seem to be quite sure that the t:updateActionListener
is correct; I certainly don't *see* any problems with it, nor do I
*experience* any problems.
If you are going to say "It should not be a problem with getter and
setter" then I'm not sure that this list can be much more help. Looks
like you'll have to step through the updateActionListener with a
debugger - or build your own custom version with extra logging in it.
Regards,
Simon
Madhav Bhargava wrote:
Hi Simon,
The version of Myfaces that I am using is from a nightly build version
1.1.5.
Tomahawk version is 1.1.5 as well (some nightly build)
displayText is a String property and getter and setter have been
generated using Eclipse so I am sure that there is no problem with the
signature.
It should not be a problem with getter and setter as literal String
values are getting set properly in the backing bean.
Regards,
Madhav
-----Original Message-----
From: Simon Kitching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 07, 2007 12:35 PM
To: MyFaces Discussion
Subject: Re: how do you pass/set parameters upon ActionListener
execution?-puzzled
Sorry I didn't read the whole mail.
How exactly is "msg" defined?
I don't see here what version of Tomahawk you are working with. For
version 1.1.3 (which is what I have at hand) the value is fetched just
using a standard call to "getValue()", so there's nothing special
there.
However afterwards it tries to do some type-conversion:
Object v = getValue();
if (v != null &&
v instanceof String)
{
Class type = updateBinding.getType(context);
....
}
updateBinding.setValue(context, v);
If expression breadCrumbNavigatorBean.displayText doesn't reference a
String property then there might be a conversion problem. Note that
exactly what defines a javabean "property" is slightly more complex
than
just having a setter method. For example, the setter must not be
static,
and there must not be a getter method with a conflicting signature.
You
could check by using java.bean.Introspector on this class and verify
that it does agree that there is indeed a writeable String property
"displayText". Ok, it's not likely that this is wrong but
t:updateActionListener is in wide use and there are no known problems
with it so something odd is going on..
Cheers,
Simon
Madhav Bhargava wrote:
As I mentioned in point number 2 it works. displayText property in
the
backing bean will get populated with "dummyValue"
The immediate inference of this result was that there is something
wrong
with my EL expression. But then when I used <t:outputLabel> tag with
the
same EL expression it outputted the correct value.
This means that there is nothing wrong with the EL expression. The
key
is properly defined in the Messages.properties file as well.
~madhav
-----Original Message-----
From: Simon Kitching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 07, 2007 12:20 PM
To: MyFaces Discussion
Subject: Re: how do you pass/set parameters upon ActionListener
execution?- puzzled
What happens if you do this?
<t:updateActionListener
property="#{breadCrumbNavigatorBean.displayText}"
value="dummyValue"/>
Madhav Bhargava wrote:
Hi Werner,
I double checked the jsp and the backing bean but it just refuses
to
parse the EL expression.
This is what I have done:
*Jsp Code:*
<t:commandLink value="Add Reminders" styleClass="linkClass"
action="#{reminderController.getExistingRemindersList}"
actionListener="#{breadCrumbNavigatorBean.updateBreadCrumb}"
rendered="#{!physicianHomeController.showRemindersMoreLink}">
<t:updateActionListener
property="#{breadCrumbNavigatorBean.displayText}"
value="#{msg['breadcrumb.label.reminders']}"/>
</t:commandLink>
In the* backing bean* I just defined a String property with the
name
displayText.
*/Following is the observation:/*
1. The displayText in the backing bean is null. In other words the
EL
expression does not get parsed resulting in a null value.
2. If a literal string is given in place of an EL expression then
the
value is correctly populated in the backing bean.
3. Based on the result from point number 2 - I tried just
outputting
the
value of the EL expression using: <t:outputLabel
value="#{msg['breadcrumb.label.reminders']}"
styleClass="outputLabelText"/> The same expression is now parsed
properly and the value appears on the page. This means that there
is
nothing wrong with the EL expression.
I am not sure what is going on? Why will <t:updateActionListener>
refuse
to parse an EL expression that references a message bundle?
Regards,
Madhav
-----Original Message-----
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Werner Punz
Sent: Tuesday, March 06, 2007 4:10 PM
To: [email protected]
Subject: Re: how do you pass/set parameters upon ActionListener
execution?
I had similar usescases (although not using
internationalisation)
in my current up a dozend times, the mechanism itself works,
I can only guess here,
first of all which myfaces version do you use and which tomahawk
version.
I can recommend to go to the latest 1.1.5 stable and use the
tomahawk
and sandbox nightlies.
Secondly check for typos nav.msg.remiders seems like one
there is an "n" missing in reminders typowise, which could
be the cause for an empty string issued.
Werner
Madhav Bhargava schrieb:
> Hi Werner,
>
> Yes, you are right. But I still cannot get the values in my
backing
bean.
>
> *Jsp code:*
>
> <t:commandLink value="Add Reminders" styleClass="linkClass"
> action="#{reminderController.showAddReminderScreen}"
>
> actionListener="#{breadCrumbNavigatorBean.updateBreadCrumb}"
> rendered="#{!physicianHomeController.showRemindersMoreLink}">
>
> <t:updateActionListener
> property="#{breadCrumbNavigatorBean.participant.displayText}"
> value="#{msg['nav.msg.remiders']}"/>
>
> </t:commandLink>
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION
intended
solely for the use of the addressee(s). If you are not the intended
recipient, please notify the sender by e-mail and delete the original
message. Further, you are not to copy, disclose, or distribute this
e-mail
or its contents to any other person and any such actions are unlawful.
This e-mail may contain viruses. Infosys has taken every reasonable
precaution to minimize this risk, but is not liable for any damage you
may
sustain as a result of any virus in this e-mail. You should carry out
your
own virus checks before opening the e-mail or attachment. Infosys
reserves
the right to monitor and review the content of all messages sent to or
from this e-mail address. Messages sent to or from this e-mail address
may
be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
