It'll work because it's printed during render view, not build view.
Cheers, B
On Wed, Jan 14, 2015 at 7:03 PM, manfred riem <manfred.riem_at_oracle.com>
wrote:
> Hi all,
>
> On 1/14/15, 11:58 AM, Bauke Scholtz wrote:
>
> Not a chicken-egg problem.
>
> I disagree cordially ;)
>
> PrimeFaces #{p:component('componentId')} already does exactly this:
> http://www.primefaces.org/docs/vdl/5.0/core/primefaces-p/component.fn.html
>
> RichFaces also has several since ages:
> http://docs.jboss.org/richfaces/latest_4_5_X/Component_Reference/en-US/html/chap-Component_Reference-Functions.html
>
> I myself just use component binding, but this is not always clearly
> understood by starters (who usually also don't always clearly see the wall
> between server side and client side).
>
> <h:someComponent id="foo" binding="#{foo}" />
> <script>var foo = document.getElementById('#{foo.clientId}');</script>
>
> What if you put the script section before the <h:someComponent>, which is
> perfectly legal?
>
> Cheers, B
>
> On Wed, Jan 14, 2015 at 6:42 PM, Leonardo Uribe <leonardo.uribe_at_irian.at>
> wrote:
>
>> 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 <%2B1%20203-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
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>>
>> >>
>>
>
>