It's an inner class of LoadBundleTag, so in your classpath the binary
class will be LoadBundleTag$BundleMap.
http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/taglib/core/LoadBundleTag.java
Ernani wrote:
Hello Simon,
I am really unable to find the class you've suggested named BundleMap.
Well, at least I do not have it in my classpath :).
Would you mind pointing it out?
Best Regards,
Ernani
Simon Kitching-3 wrote:
Hi Ernani,
If your application always uses the same values for the f:loadBundle tag
attributes (ie basename and var are always the same) then you might be
able to work around this problem with a hack: write a PhaseListener,
then on post-restore-view, do this:
ResourceBundle bundle = somehowLoadTheDesiredBundle();
String var = "whatever the f:loadBundle var attribute is set to";
facesContext.getExternalContext().getRequestMap().put(
var,
new BundleMap(bundle));
The BundleMap class just makes a ResourceBundle acessable via the Map
interface. You can copy it from the original class:
org.apache.myfaces.taglib.core.LoadBundleTag.
The above is ugly but probably the easiest solution in many cases.
A proper fix would involve writing a tag to replace the LoadBundleTag
and then changing your pages to reference this new tag, eg
<my:loadBundle basename=".." var="..."/>
Not sure what the best implementation for the new tag would be. I guess
a UIComponent subclass could be created as for normal tags. Its
saveState method would just save the basename and var. Its restoreState
method would then load a bundle using basename and re-register it using
var.
That's not *too* hard, but not trivial either.
BTW, I'm not *sure* that Shawn's problem is the same. I don't remember
him mentioning anything about message bundles, just that "f:attribute
doesn't work".
The JSF phases should be well described in any JSF textbook; it's the
most fundamental concept of all.
You'll find lots of useful info on the myfaces wiki:
http://wiki.apache.org/myfaces/
Regards,
Simon
Ernani wrote:
Hello Simon,
You said
The fix is probably to update the f:loadBundle tag to reload
the
bundle during the restore-view phase.
I am not familiar how to do this, I think I still need more study on the
Faces phases. How do you suggest us to fix? Me and Shawn have the same
problem.
Any code snippet or source explaining this would be highly appreciated.
Best Regards,
Ernani
Simon Kitching-3 wrote:
Ah.. Shawn, the value you are missing isn't taken from a message bundle
is it?
There was a question on this list a month or so ago about using an EL
expression to get a value from a message bundle. The f:loadBundle tag
currently only works in the "render" phase, and does nothing on
restore-view. This means that any EL expression referencing the message
bundle will return null during postback processing.
This isn't normally a problem; messages from message-bundles are
normally used just to output text. However if for some reason anyone
tries to reference one in the postback (eg from a t:updateActionListener
or t:aliasBean) then it won't currently work.
And as noted earlier in this thread, prior to myfaces 1.1.5 an
f:attribute was evaluated once only and the result of the expression
stored as the parent component's attribute. In 1.1.5 and later the
*expression* is now stored and evaluated each time it is used. And of
course the *first* time the f:attribute is encountered is during a
render phase. So if you use an f:attribute to access a message bundle,
then it would work in pre-1.1.5 because it evaluates once (during a
render phase) and stores the resulting string. Even when that attribute
is fetched during a postback phase it will be there. However since 1.1.5
it will be the *el expression* that is fetched and evaluated - so the
message-bundle is not loaded so the expression will evaluate to null in
the postback phase (and will work fine in the render phase).
The fix is probably to update the f:loadBundle tag to reload the bundle
during the restore-view phase.
Regards,
Simon
Ernani wrote:
I have the same issue here, just upgraded and it is missing all
parameters
for messages.
Please let me know if you figure it out how to resolve this problem.
Otherwise I will have to downgrade the MyFaces version.
Thanks.
Ernani
Garner, Shawn-2 wrote:
I upgraded to 1.1.5 and now my phase listener can no longer get my
f:attribute attribute on a component (eg: <h:inputText>).
I iterate over the client IDs with messages by doing
FacesContext.getClientIdsWithMessages();
I get the component by UIViewRoot.findComponent(clientID) and then try
to get the attribute by String fieldRef =
component.getAttributes().get("fieldRef");
It worked before I upgraded.
Can somebody help me?
Shawn
