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

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

From: Leonardo Uribe <leonardo.uribe_at_irian.at>
Date: Wed, 14 Jan 2015 12:42:30 -0500

Hi

I just forgot to say that the clientId is used a an identifier bound
to the HTML "id" attribute, and in that way it follows the rules that
HTML says. But the widgetVar is an identifier for javascript,
but its purpose is client side only.

regards,

Leonardo Uribe

2015-01-14 12:30 GMT-05:00 Leonardo Uribe <leonardo.uribe_at_irian.at>:
> Hi
>
> There is a relationship between the widgetVar and the clientId. For
> example in primefaces if no widgetVar is set, by default it uses:
>
> "widget_" + clientId.replace(/:/g, "_")
>
> Use widgetVar has the advantage that you can use it directly on the
> javascript. For example:
>
> myDialogWidget.doSomething();
>
> The disadvantage with widgetVar is if you have two components with the
> same widgetVar, it will be a conflict in javascript, so it affects
> code reusal (a component with a widgetVar set will not work well
> inside a dataTable). But on the other side, it is cleaner for
> javascript users, because sometimes you need just to add a couple of
> lines.
>
> The alternative is use a EL function and mix it with javascript:
>
> #{myLib:toJavascriptVar('myClientId')}.doSomething();
>
> This works well from reusal perspective, because the javascript
> variable is generated at render time, but note facelets compiler needs
> to parse the javascript.
>
> It is a fact that if you have a component enhanced with javascript,
> you need to create a javascript object, no matter how is called and
> that javascript object will be associated with a html tag. The current
> clientId has the problem that it uses ':', so it is not a valid
> javascript variable name. The need is have something that generates a
> valid javascript name that can be associated with the component in a
> unique way. In other words a javascript variable name "derived" from
> the clientId.
>
> From JSF perspective, this is something related to the RenderKit, but
> this is a common concept and looks like a good idea to standarize it.
> Why? because sometimes a parent component could need a way to
> reference its children not on the server but on the client to do
> something (invoke a client side javascript function for example).
>
> The justification for this feature looks solid in my opinion. +1
>
> regards,
>
> Leonardo Uribe
>
>
> 2015-01-14 10:40 GMT-05:00 Kito Mann <kito.mann_at_virtua.com>:
>> 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 | @jsfcentral
>>>>> +1 203-998-0403
>>>>>
>>>>> * Listen to the Enterprise Java Newscast: http://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
>>>>>>
>>>>>
>>>>
>>>
>>>
>>