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