Of course, whether the HTML element itself is available is a second (and
unrelated to JSF), but the point was that #{foo.clientId} works regardless
of the location in the view.
Cheers, B
On Wed, Jan 14, 2015 at 7:39 PM, Leonardo Uribe <leonardo.uribe_at_irian.at>
wrote:
> Hi
>
> MR>> What if you put the script section before the <h:someComponent>,
> which is perfectly legal?
>
> BS>> It'll work because it's printed during render view, not build view.
>
> I guess the element will not be found when the javascript is called,
> because the page has not been loaded.
>
> But anyway, it is a matter about how you write the javascript:
>
> <script>
> jQuery(document).ready(function() {
> var foo = document.getElementById('#{foo.clientId}');
> });
> </script>
> <h:someComponent id="foo" binding="#{foo}" />
>
> In fact there is a small lifecycle:
>
> - Load the page / Widget initialization
> - invoke load functions
>
> We could create a custom jsf javascript function for that stuff
> if required.
>
> But I can't imagine why someone would put the script before
> the tag.
>
> regards,
>
> Leonardo Uribe
>
> 2015-01-14 13:03 GMT-05:00 manfred riem <manfred.riem_at_oracle.com>:
> > 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
> >> >>>>>
> >> >>>>> * 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
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>
> >
> >
>