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
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>
>