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