The partial search would begin under the context of the component
which is identified by the currentClientId in the
myfacesContext-implicit variable.
Note that this solution means you have to "bind" (respectively store
the client id of) only the naming-container, not the component itself.
regards,
Martin
On 9/21/06, Michael Youngstrom <[EMAIL PROTECTED]> wrote:
What do you mean when you refer to a partial id search? Under what
context would the partial search begin?
I'm personally still like the approach of the current ifMessage
component. It consistently solves the problem in all the situations
we've discussed. But I'm still open to discussing other options. I
think an ifMessage variableResolver tool that takes a full client Id
would work fine for some cases...it just gives me the willies thinking
of hard coding full client ids in the page itself. it also gives me
the willies thinking of having to bind components to a backing bean
just to get their client id to use in the ifMessage Variable resolver.
Would become quite a pain for large forms.
Mike
On 9/20/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> 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
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
