Well, once you disassociate the parent from the el expression, you've
made setting up, maintaining, and debugging it harder. And you've
limited yourself to exactly one ifMessage expression client-id target
for any particular panel. And you've introduced scoping problems.
Worse case, if we have the full path in the expression, one could bind
the component to a backing bean, then query the bean for the client-id
path.
rendered="#{myfacesContext.ifMessage[myBean.targetComponent.clientId]}"
On 9/20/06, Michael Youngstrom <[EMAIL PROTECTED]> wrote:
> Seems like we should be discussing this on dev rather than in the issue
tracker. Few people are going to be following the issue.
Done
>
> In my opinion, I don't see why you wouldn't use
>
> <h:panelGroup rendered="#{myfacesContext.ifMessage['someForm:name']}">
>
> That's far less limiting that having to set something with a taghandler.
>
Some of the problems I see right off the bat with having to put the
entire client id into the ifMessage expression are:
1. If these elements or this form is included in multiple places with
different base client ids it would cause some problems.
2. How would something like that work with input components placed
inside a UIData?
Mike
