Re: DHTML scripting and JSF apps
Hi Simon,
You're right about Tiles, and I can see the issues you've mentioned.
I ended up doing something like what you suggested - in my case I've
just used predictable suffixes for the various things I need to get
to: this.id + Label, this.id + Help, etc.
Thanks to all for the advice, and for putting up with a newbie as I
get my head around this stuff.
--Steve
On 12/12/05, Simon Kitching [EMAIL PROTECTED] wrote:
From the fact that you've got a naming container with id content in
the hierarchy, it looks like you're using Tiles to compose pages. This
is a prime example of where conflicting ids can occur when forceId is
used: the authors of all the parts used to compose a page must ensure
they don't use the same ids in different parts. For me, forceId is like
hacking Java so that class member variable names can conflict. Yecch.
Are you aware that in event-handler code called from a DOM component (eg
an onclick, the called javascript method can use this to refer to
the component that the event fired on? This can remove the need to know
the component's id at all in some cases.
Regards,
Simon
Mike Kienenberger wrote:
The naming is based on NamingContainers.
* If this component is a descendant of a NamingContainer then the
* client id is of form {namingContainerId}:{componentId}.
I can't remember all of which components implement NamingContainer,
but I think it's UIForm and UIData. UIData uses
{namingContainerId}:{componentId_#}, I believe.
I think there's also a tomahawk extension attribute called forceId,
which, when set to true, will bypass naming containers and use the raw
id value specified, but I haven't used it.
http://myfaces.apache.org/tomahawk/forceId.html
On 12/12/05, Steve Ivy [EMAIL PROTECTED] wrote:
Hello,
I'm working on the front end for a JSF app, and I'm trying to add some
interactivitiy to the interface via javascript. Typically you do a lot
of:
document.getElementById ('someId').etc ()
But I find that setting the id in JSF usually results in something
like id=content:_id35:nameHelp. I'm not sure how these ids are
assigned, and I'm not sure how I can predict what id an element will
have in order to acess it via javascript (or css for that matter, but
that's another rant). Are there accepted methods of getting around
this?
Thanks,
--Steve
--
Steve Ivy
http://redmonk.net
--
Steve Ivy
http://redmonk.net
Re: DHTML scripting and JSF apps
The naming is based on NamingContainers.
* If this component is a descendant of a NamingContainer then the
* client id is of form {namingContainerId}:{componentId}.
I can't remember all of which components implement NamingContainer,
but I think it's UIForm and UIData. UIData uses
{namingContainerId}:{componentId_#}, I believe.
I think there's also a tomahawk extension attribute called forceId,
which, when set to true, will bypass naming containers and use the raw
id value specified, but I haven't used it.
http://myfaces.apache.org/tomahawk/forceId.html
On 12/12/05, Steve Ivy [EMAIL PROTECTED] wrote:
Hello,
I'm working on the front end for a JSF app, and I'm trying to add some
interactivitiy to the interface via javascript. Typically you do a lot
of:
document.getElementById ('someId').etc ()
But I find that setting the id in JSF usually results in something
like id=content:_id35:nameHelp. I'm not sure how these ids are
assigned, and I'm not sure how I can predict what id an element will
have in order to acess it via javascript (or css for that matter, but
that's another rant). Are there accepted methods of getting around
this?
Thanks,
--Steve
--
Steve Ivy
http://redmonk.net
Re: DHTML scripting and JSF apps
Steve Ivy wrote:
Hello,
I'm working on the front end for a JSF app, and I'm trying to add some
interactivitiy to the interface via javascript. Typically you do a lot
of:
document.getElementById ('someId').etc ()
But I find that setting the id in JSF usually results in something
like id=content:_id35:nameHelp. I'm not sure how these ids are
assigned, and I'm not sure how I can predict what id an element will
have in order to acess it via javascript (or css for that matter, but
that's another rant). Are there accepted methods of getting around
this?
the ids usually are assigned by nesting hierarchy, if you use the ids
explicitely you basically get the nested elements divided by :
ie.:
view id=viewid
form id=myform
element id=element
results in an id for the element of viewid:myform:element
however myfaces has something much easier in the tomahawk components,
you can use the forceid attribute then with following
element id=element forceid=true you get an exact form id of element
for your element
Re: DHTML scripting and JSF apps
Thanks all,
I've looked at forceId, and it looks like it will do what I'm looking
for in a limited context. However, there appears to be a gap in api
coverage between JSF and myfaces: JSF provide tags for things like
form labels, spans (via outputText) etc, but these elements inherit
the namingContainer behavior, which I'm trying to override.
Tomahawk provides forceId for all its custom components, but has no
equivalent way to output the kinds of tags I need. Tomahawk *does*
provide htmlTag, but it's a very limited component that does not
appear to provide for any attributes other than the tag name (via
htmltag's _value_ attribute) so I cannot use it for any tag that
requires oather attributes to be set (like label's _for_ attribute or
the _title_ attribute).
I'm not sure where to go from here, to be honest.
--Steve
On 12/12/05, Werner Punz [EMAIL PROTECTED] wrote:
Steve Ivy wrote:
Hello,
I'm working on the front end for a JSF app, and I'm trying to add some
interactivitiy to the interface via javascript. Typically you do a lot
of:
document.getElementById ('someId').etc ()
But I find that setting the id in JSF usually results in something
like id=content:_id35:nameHelp. I'm not sure how these ids are
assigned, and I'm not sure how I can predict what id an element will
have in order to acess it via javascript (or css for that matter, but
that's another rant). Are there accepted methods of getting around
this?
the ids usually are assigned by nesting hierarchy, if you use the ids
explicitely you basically get the nested elements divided by :
ie.:
view id=viewid
form id=myform
element id=element
results in an id for the element of viewid:myform:element
however myfaces has something much easier in the tomahawk components,
you can use the forceid attribute then with following
element id=element forceid=true you get an exact form id of element
for your element
--
Steve Ivy
http://redmonk.net
Re: DHTML scripting and JSF apps
If you're programmically building the javascript, you can just output
component.getClientId(FacesContext) and it'll generate the
fully-qualified id for you.
You can get a reference to component by binding it to your backing bean.
I don't understand your comment about a gap between JSF and MyFaces.
MyFaces is a JSF implementation. Any gaps would be a bug.
On 12/12/05, Steve Ivy [EMAIL PROTECTED] wrote:
Thanks all,
I've looked at forceId, and it looks like it will do what I'm looking
for in a limited context. However, there appears to be a gap in api
coverage between JSF and myfaces: JSF provide tags for things like
form labels, spans (via outputText) etc, but these elements inherit
the namingContainer behavior, which I'm trying to override.
Tomahawk provides forceId for all its custom components, but has no
equivalent way to output the kinds of tags I need. Tomahawk *does*
provide htmlTag, but it's a very limited component that does not
appear to provide for any attributes other than the tag name (via
htmltag's _value_ attribute) so I cannot use it for any tag that
requires oather attributes to be set (like label's _for_ attribute or
the _title_ attribute).
I'm not sure where to go from here, to be honest.
--Steve
On 12/12/05, Werner Punz [EMAIL PROTECTED] wrote:
Steve Ivy wrote:
Hello,
I'm working on the front end for a JSF app, and I'm trying to add some
interactivitiy to the interface via javascript. Typically you do a lot
of:
document.getElementById ('someId').etc ()
But I find that setting the id in JSF usually results in something
like id=content:_id35:nameHelp. I'm not sure how these ids are
assigned, and I'm not sure how I can predict what id an element will
have in order to acess it via javascript (or css for that matter, but
that's another rant). Are there accepted methods of getting around
this?
the ids usually are assigned by nesting hierarchy, if you use the ids
explicitely you basically get the nested elements divided by :
ie.:
view id=viewid
form id=myform
element id=element
results in an id for the element of viewid:myform:element
however myfaces has something much easier in the tomahawk components,
you can use the forceid attribute then with following
element id=element forceid=true you get an exact form id of element
for your element
--
Steve Ivy
http://redmonk.net
Re: DHTML scripting and JSF apps
Hm. I think it's not a gap in MyFaces, just in the extensions (tomahawk?). The extensions provide the forceId functionality but not for any JSF component, only for the extension components I think. Anyway, I've decided to forgo the whole thing and build the path to the elements I need in javascript, and just accept that the extra path info is always going to be in the element ids. --Steve On 12/12/05, Mike Kienenberger [EMAIL PROTECTED] wrote: I don't understand your comment about a gap between JSF and MyFaces. MyFaces is a JSF implementation. Any gaps would be a bug. On 12/12/05, Steve Ivy [EMAIL PROTECTED] wrote: Thanks all, -- Steve Ivy http://redmonk.net
Re: DHTML scripting and JSF apps
Steve Ivy wrote: Hm. I think it's not a gap in MyFaces, just in the extensions (tomahawk?). The extensions provide the forceId functionality but not for any JSF component, only for the extension components I think. Actually no, the tomahawk extensions have eqivalents for most of not all standard jsf components, you will find a t:form for instance as well as a t:inputText or t:commandLink the only missing component I found recently was a t:outputformat, but the functionality might be hidden in t:outputtext (I have not looked into it) The reason for this is, that you cannot extend the functionality of the standard components (I am not sure but I think forceid was the reason for the component duplication) thus all the components are mirrored in Tomahawk. Anyway, I've decided to forgo the whole thing and build the path to the elements I need in javascript, and just accept that the extra path info is always going to be in the element ids. Yes, it is, but make sure you set the ids of the parent components explicitely, otherwise you might run into troubles with the auto id generation.
