jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: [jsr372-experts mirror] [49-JsClientId] JS function for "give me the clientId"

From: Kito Mann <kito.mann_at_virtua.com>
Date: Wed, 14 Jan 2015 10:40:23 -0500

I like the widgetVar and clientKey approaches, but they assume there's a
client-side JS widget for each component, which isn't the case for the
standard components....

On Tue, Jan 13, 2015 at 7:22 PM, Neil Griffin <neil.griffin_at_portletfaces.org
> wrote:

> Liferay Faces has a similar feature that uses the attribute name
> "clientKey" since it refers to a lookup in a key/value map in the
> client-side JS.
>
> For example:
>
> <alloy:button onclick="Liferay.component('dialogKey1').toggle();">
> <alloy:dialog clientKey="dialogKey1">
> ...
> </alloy:dialog>
> </alloy:button>
>
>
> On Jan 13, 2015, at 3:44 PM, manfred riem <manfred.riem_at_oracle.com> wrote:
>
> Hi Çağatay,
>
> You willing and able to research on how to standardize this and contribute
> it back to the RI?
>
> Manfred
>
> On 1/13/15, 1:50 PM, Josh Juneau wrote:
>
> To All-
>
> I agree that a solution to this issue would require some assumption on
> how things are structured. I prefer the technique utilized in PrimeFaces,
> whereby you are able to reference components via their widgetVar, rather
> than by ID. If effort were to be spent on some resolution to this issue,
> I'd rather see a standardized implementation of the widgetVar solution that
> is present in the PrimeFaces JavaScript API.
>
> Just my 2 cents.
>
> Best Regards
>
> Josh Juneau
> juneau001_at_gmail.com
> http://jj-blogger.blogspot.com
> https://www.apress.com/index.php/author/author/view/id/1866
>
>
> On Mon, Jan 12, 2015 at 11:46 AM, manfred riem <manfred.riem_at_oracle.com>
> wrote:
>
>> Hi Kito,
>>
>> It took it as the JavaScript functions getClientId() or
>> getClientId('whatever') as it is said to be JS function.
>>
>> Regards,
>> Manfred
>>
>>
>>
>> On 1/12/15, 11:33 AM, Kito Mann wrote:
>>
>> Is the JIRA issue just asking about EL evaluation (as the example
>> implies), or is it referring to a real JavaScript function?
>>
>> In other words, are they asking about this:
>>
>> <h:button id="button1"
>> onclick="button_setEnabled(*#{getClientId('button2')}*,
>> false);button_clicked(*#{getClientId('button1')}*;return"... />
>>
>> or:
>>
>> <h:button id="button1"
>> onclick="button_setEnabled(*getClientId('button2')*,
>> false);button_clicked(*getClientId('button1')*;return"... />
>>
>>
>>
>> On Mon, Jan 12, 2015 at 12:27 PM, manfred riem <manfred.riem_at_oracle.com>
>> wrote:
>>
>>> Hi Kito,
>>>
>>> Ughh, as you pointed out the client id is already there. My brain just
>>> stopped working :(.
>>>
>>> However I still want to mark this issue as "Won't fix" as there is no
>>> way of knowing how a specific component is being rendered and which HTML
>>> element corresponds to the client id of the component. And no I don't want
>>> to make any assumption on how it is structured.
>>>
>>> Thoughts?
>>> Manfred
>>>
>>>
>>> On 1/12/15, 11:13 AM, Kito Mann wrote:
>>>
>>> Manfred, can you articulate your objection more clearly? We definitely
>>> know the client id before the JavaScript executes, since it executes on the
>>> client :-).
>>>
>>> ___
>>>
>>> Kito D. Mann | @kito99 | Author, JSF in Action
>>> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
>>> consulting
>>> http://www.JSFCentral.com <http://www.jsfcentral.com/> | @jsfcentral
>>> +1 203-998-0403 <%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 Mon, Jan 12, 2015 at 12:00 PM, manfred riem <manfred.riem_at_oracle.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I like to close
>>>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-49 as "Won't
>>>> fix" as this request suffers from the chicken and the egg problem. In this
>>>> particular case we cannot make sure the client id is rendered before the
>>>> JavaScript executes.
>>>>
>>>> Thoughts?
>>>> Manfred
>>>>
>>>>
>>>
>>
>
>