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
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
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
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
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
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
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
7 matches
Mail list logo
