@Arjan,
Considering;
#{f:clientId("componentId”)}
Where you do you suggest we start search, UIViewRoot? The #p:component(‘componentId’) does it.
Also how to customize where to start search? .e.g
Regards,
Cagatay Civici
PrimeFaces Lead
PrimeTek Informatics
www.primefaces.org
On Monday 16 March 2015 at 16:22, Josh Juneau wrote:
> Hi Kito-
>
> Thanks for the response. I can definitely see your point regarding the collapse of namespace using widgetVar. I typically do not run into issues with duplicate widgetVar names because I try to be mindful of the names I've chosen...but I could see how it may be problematic in some cases.
>
> My main concern is referencing the component in JavaScript...just attempting to make this easier for the user. In my opinion, a standardized version of something like the PrimeFaces widgetVar would resolve this issue to some degree. It is much nicer to reference a single widgetVar or unique component identifier than to ensure that the component is being referenced correctly by walking the DOM to build the correct component ID.
>
> Josh Juneau
> juneau001_at_gmail.com (mailto:juneau001_at_gmail.com)
> http://jj-blogger.blogspot.com
> https://www.apress.com/index.php/author/author/view/id/1866
>
>
> On Mon, Mar 16, 2015 at 8:38 AM, Kito Mann <kito.mann_at_virtua.com (mailto:kito.mann_at_virtua.com)> wrote:
> > Hello Josh,
> >
> > I like the widgetVar, but it collapses the namespace; preserving the namespace is the whole reason we have naming containers to begin with. Moreover, not every component has a widget (at least that's true for the standard component). In other words, two components with the same name can still exist within different naming containers; this isn't true with the widgetVar naming approach. This can be problematic if you have composite components or Facelet includes that have assigned a component the same widgetVar name you have on your main page.
> >
> > Are you mainly concerned with referencing the component in JavaScript or on the server?
> >
> > ___
> >
> > Kito D. Mann | @kito99 | Author, JSF in Action
> > Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
> > http://www.JSFCentral.com | @jsfcentral
> > +1 203-998-0403 (tel:%2B1%20203-998-0403)
> >
> > * Listen to the Enterprise Java Newscast: http:// (http://blogs.jsfcentral.com/JSFNewscast/)enterprisejavanews.com (http://ww.enterprisejavanews.com)
> > * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/
> > * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
> > On Sat, Mar 7, 2015 at 10:52 AM, Josh Juneau <juneau001_at_gmail.com (mailto:juneau001_at_gmail.com)> wrote:
> > > Hi everyone-
> > >
> > > From a user perspective, it is cumbersome to reference components within JavaScript using the :form:container:component notation. It isn't bad when you have a basic form within a view, but when container components, such as TabViews or Panels come into play, then it can become a minor headache.
> > >
> > > In the PrimeFaces world, components contain an attribute "widgetVar", which is basically a pseudo ID for the component, and it is used when referencing the component using the PrimeFaces JavaScript API. It is easy to use, and less error prone/time consuming then walking the DOM tree to determine the correct component ID for complex views...where oftentimes the user has to view the sources to determine the correct ID of a component. This is the functionality that I'd like to see standardized...and I think it would make life easier for component developers as well in some cases.
> > >
> > > Hope this helps.
> > >
> > > Josh Juneau
> > > juneau001_at_gmail.com (mailto:juneau001_at_gmail.com)
> > > http://jj-blogger.blogspot.com
> > > https://www.apress.com/index.php/author/author/view/id/1866
> > >
> > >
> > > On Fri, Mar 6, 2015 at 10:42 AM, Bauke Scholtz <balusc_at_gmail.com (mailto:balusc_at_gmail.com)> wrote:
> > > > Hi,
> > > >
> > > > I'd rather first lookup in current NamingContainer. If there's nothing, then look in NamingContainer children, working up-bottom in the tree. If there's nothing, then look in NamingContainer parents, working bottom-up until UIViewRoot. That would be more intuitive in case the same ID is used in multiple NamingContainers.
> > > >
> > > > Cheers, B
> > > >
> > > > On Fri, Mar 6, 2015 at 5:08 PM, arjan tijms <arjan.tijms_at_gmail.com (mailto:arjan.tijms_at_gmail.com)> wrote:
> > > > > Hi
> > > > >
> > > > > On Fri, Mar 6, 2015 at 12:14 AM, Cagatay Civici
> > > > > <cagatay.civici_at_gmail.com (mailto:cagatay.civici_at_gmail.com)> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Sorry for the late reply, due to ongoing workload I was unable to look into
> > > > > > it.
> > > > > >
> > > > > > Arjan if you think you can allocate some time instead, I’d really appreciate
> > > > > > your help.
> > > > >
> > > > > Sure for general (serverside) ID lookup/find issues I'm always willing
> > > > > to help out. If I understood correctly, there's no javascript really
> > > > > involved here right? It's just an EL function?
> > > > >
> > > > > E.g. that EL function itself will become something like:
> > > > >
> > > > > #{f:clientId("componentId")}
> > > > >
> > > > > In OmniFaces we have a couple of find component utility methods, that
> > > > > basically do relative lookup. My first stab at this would be to use a
> > > > > method like the following:
> > > > >
> > > > > https://github.com/omnifaces/omnifaces/blob/master/src/main/java/org/omnifaces/util/Components.java#L203
> > > > >
> > > > > And then feed UIComponent.getCurrentComponent(FacesContext.getCurrentInstance())
> > > > > as the first parameter.
> > > > >
> > > > > This will, starting from the "current component", first look in the
> > > > > naming container parents and if it fails to find the component there
> > > > > in the children from the view root, working down.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Kind regards,
> > > > > Arjan
> > > > >
> > > > >
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Cagatay Civici
> > > > > > PrimeFaces Lead
> > > > > > PrimeTek Informatics
> > > > > > www.primefaces.org (http://www.primefaces.org)
> > > > > >
> > > > > > On Wednesday 25 February 2015 at 20:32, arjan tijms wrote:
> > > > > >
> > > > > > Hi Cagatay,
> > > > > >
> > > > > > Just curious, but any progress to report here?
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > Kind regards,
> > > > > > Arjan
> > > > > >
> > > > > > On Monday, January 26, 2015, manfred riem <manfred.riem_at_oracle.com (mailto:manfred.riem_at_oracle.com)> wrote:
> > > > > >
> > > > > > Hi Cagatay,
> > > > > >
> > > > > > I have assigned it to you.
> > > > > >
> > > > > >
> > > > > > Thanks!
> > > > > > Manfred
> > > > > >
> > > > > > On 1/26/15, 6:33 AM, Cagatay Civici wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > It is cagatay_civici.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Cagatay Civici
> > > > > > PrimeFaces Lead
> > > > > > PrimeTek Informatics
> > > > > > www.primefaces.org (http://www.primefaces.org)
> > > > > >
> > > > > > On Thursday 22 January 2015 at 20:23, manfred riem wrote:
> > > > > >
> > > > > > Whoops,
> > > > > >
> > > > > > Can you let me know what your java.net (http://java.net) id is?
> > > > > >
> > > > > > Thanks!
> > > > > > Manfred
> > > > > >
> > > > > > On 1/22/15, 12:19 PM, manfred riem wrote:
> > > > > >
> > > > > > Hi Cagatay,
> > > > > >
> > > > > > Thanks! I'll assign to you it and please let us know how it goes :)
> > > > > >
> > > > > > Regards,
> > > > > > Manfred
> > > > > >
> > > > > > On 1/22/15, 12:15 PM, Cagatay Civici wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > ACTION: Cagatay, may we assign [49-jsClientId] [1] to you? As part of
> > > > > > owning this, can you please create a text document of the specification
> > > > > > for this. It should probably reside inside the f:tag library. The
> > > > > > specification must be clean-room implementable, of course.
> > > > > >
> > > > > > Sorry for the late reply, it has been a busy week. Sure please assign it to
> > > > > > me and I’ll work on it.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Cagatay Civici
> > > > > > PrimeFaces Lead
> > > > > > PrimeTek Informatics
> > > > > > www.primefaces.org (http://www.primefaces.org)
> > > > > >
> > > > > > On Tuesday 20 January 2015 at 21:15, Edward Burns wrote:
> > > > > >
> > > > > > On Wed, 14 Jan 2015 18:58:16 +0100, Bauke Scholtz <balusc_at_gmail.com (mailto:balusc_at_gmail.com)> said:
> > > > > >
> > > > > >
> > > > > > BalusC> PrimeFaces #{p:component('componentId')} already does exactly
> > > > > > BalusC> this:
> > > > > > BalusC>
> > > > > > http://www.primefaces.org/docs/vdl/5.0/core/primefaces-p/component.fn.html
> > > > > >
> > > > > > On Thu, 15 Jan 2015 08:01:53 -0600, manfred riem <manfred.riem_at_oracle.com (mailto:manfred.riem_at_oracle.com)>
> > > > > > said:
> > > > > >
> > > > > >
> > > > > > MR> So Cagatay are you willing and able to push this issue further
> > > > > > MR> along?
> > > > > >
> > > > > > ACTION: Cagatay, may we assign [49-jsClientId] [1] to you? As part of
> > > > > > owning this, can you please create a text document of the specification
> > > > > > for this. It should probably reside inside the f:tag library. The
> > > > > > specification must be clean-room implementable, of course.
> > > > > >
> > > > > > Ed
> > > > > >
> > > > > > --
> > > > > > | edward.burns_at_oracle.com (mailto:edward.burns_at_oracle.com) | office: +1 407 458 0017 (tel:%2B1%20407%20458%200017)
> > > > > > | 33 days til DevNexus 2015
> > > > > > | 43 days til JavaLand 2015
> > > > > > | 53 days til CONFESS 2015
> > > > > >
> > > > > > [1] https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-49
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > >
> >
>