myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek" <martin.marinsc...@gmail.com>
Subject Re: [jira] Commented: (MYFACES-1197) Docs for ifMessage component
Date Thu, 21 Sep 2006 00:52:03 GMT
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 <youngm@gmail.com> 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 <martin.marinschek@gmail.com> 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 <mkienenb@gmail.com> 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 <youngm@gmail.com> 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

Mime
View raw message