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
* 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> 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
> 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> 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>
>> wrote:
>>
>>> Hi
>>>
>>> On Fri, Mar 6, 2015 at 12:14 AM, Cagatay Civici
>>> <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
>>> >
>>> > 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>
>>> 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
>>> >
>>> > On Thursday 22 January 2015 at 20:23, manfred riem wrote:
>>> >
>>> > Whoops,
>>> >
>>> > Can you let me know what your 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
>>> >
>>> > 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>
>>> 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>
>>> > 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 | office: +1 407 458 0017
>>> > | 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
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>
>>
>