Well, you could offer both - full client id and partial id. First
initiate a search viewing the parameter as a partial id, if that
fails, do another one interpreting the parameter as the full
client-id.
regards,
Martin
On 9/21/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
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
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
