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 <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <tel:%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 <mailto: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
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
>
>