>>>>> On Tue, 13 Jan 2015 13:50:33 -0600, Josh Juneau <juneau001_at_gmail.com> said:
JJ> I agree that a solution to this issue would require some assumption on how
JJ> things are structured. I prefer the technique utilized in PrimeFaces,
JJ> whereby you are able to reference components via their widgetVar, rather
JJ> than by ID. If effort were to be spent on some resolution to this issue,
JJ> I'd rather see a standardized implementation of the widgetVar solution that
JJ> is present in the PrimeFaces JavaScript API.
[Discussion on differences between WidgetVar and p:component deleted.]
>>>>> On Tue, 13 Jan 2015 19:22:49 -0500, Neil Griffin <neil.griffin_at_portletfaces.org> said:
NG> Liferay Faces has a similar feature that uses the attribute name
NG> "clientKey" since it refers to a lookup in a key/value map in the
NG> client-side JS.
LU> From JSF perspective, this is something related to the RenderKit, but
LU> this is a common concept and looks like a good idea to standarize it.
LU> Why? because sometimes a parent component could need a way to
LU> reference its children not on the server but on the client to do
LU> something (invoke a client side javascript function for example).
LU> The justification for this feature looks solid in my opinion. +1
>>>>> On Wed, 14 Jan 2015 18:58:16 +0100, Bauke Scholtz <balusc_at_gmail.com> said:
BalusC> Not a chicken-egg problem.
BalusC> PrimeFaces #{p:component('componentId')} already does exactly this:
BalusC>
http://www.primefaces.org/docs/vdl/5.0/core/primefaces-p/component.fn.html
BalusC> RichFaces also has several since ages:
BalusC>
http://docs.jboss.org/richfaces/latest_4_5_X/Component_Reference/en-US/html/chap-Component_Reference-Functions.html
>>>>> On Wed, 14 Jan 2015 14:26:21 -0500, Leonardo Uribe <leonardo.uribe_at_irian.at> said:
LU> Yes. The point is if there is a known solution to a problem that
LU> every third-party vendor has its own variant and is widely used,
LU> that problem is a good candidate to be included in the
LU> standard.
LU> The important thing is include something to get access to the
LU> client-side counterpart of a component from the client, for
LU> the components that has a client side counterpart or "widget".
LU> Not all components fall under that category of course, but
LU> a lot of components in JSF third party libraries has that
LU> structure.
>>>>> On Thu, 15 Jan 2015 08:28:01 +0100, Bauke Scholtz <balusc_at_gmail.com> said:
BalusC> I don't consider that part to be a problem which needs to be covered by JSF
BalusC> spec. This is just JS specific. A sane JS developer should for long know
BalusC> that the DOM element is only accessible once it has been inserted in the
BalusC> DOM. A sane JS developer would just use <h:outputScript target="body"> or
BalusC> window.addEventListener("load", func) or even $(document).ready(func).
BalusC> If you really need it to be part of JSF spec, just specify that it must be
BalusC> rendered like <h:outputScript target="body">.
>>>>> On Thu, 15 Jan 2015 11:42:27 +0200, Cagatay Civici <cagatay.civici_at_gmail.com> said:
CC> So Im +1 for a standard server function to return client id, it is
CC> very useful for client side scripting but a standard javascript is
CC> probably not needed, it is simple to access the element with
CC> javascript using the server side function that gives the client id.
>>>>> On Thu, 15 Jan 2015 08:01:53 -0600, manfred riem <manfred.riem_at_oracle.com> said:
MR> So Cagatay are you willing and able to push this issue further along?
I like the simplcity of having this as a server side function. I was
initially envisioning it as a client side function, but now see that
having it as a server side thing makes more sense.
I also would like to ask if Cagatay is willing to donate this feature to
the spec?
Thanks,
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 35 days til DevNexus 2015
| 45 days til JavaLand 2015
| 55 days til CONFESS 2015