Hi Bauke, Leonardo,
And the script execution is really what I was looking at. If the script
block
is before the HTML it can execute before.
While we might know that is not smart, it does not mean people won't
try, and if it does not work file bugs.
Hence the chicken and the egg.
Manfred
On 1/14/15, 12:44 PM, Bauke Scholtz wrote:
> 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 <mailto: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
> <mailto: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 <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
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>
> >
> >
>
>