Reported by @edburns

from javaserverfaces-spec.

@edburns said:

On Wed, 05 Jan 2005 14:58:41 -0500, Sean Schofield
[email protected] said:

SS> To Whom It May Concern:
SS> It would be nice if the convertClientId (of the Renderer interface)
SS> method took an additional argument of UICommand. Most of the other
SS> methods on this interface have this reference available to them.

SS> I was trying to write my own renderer that would optionally convert
SS> the id attribute to the one that the user initially provided (instead
SS> of the one that faces generates.) The plan was to make sure the id
SS> was unique and to have this functionality controlled by a "forceId"
SS> attribute on an extended HTML tag set.

SS> I was basically thwarted because there was no way I could learn
SS> whether or not the attribute was set and nor could I learn the
SS> original Id (although that could be guessed by stripping everything
SS> before last ':' char.)

SS> Please consider modifying this in the 1.2 specification. Also, I
SS> would suggest adding more explanation about this function and when it
SS> is supposed to be called. I couldn't find it in the spec other than a
SS> one sentance javadoc type statement (maybe I missed it though.)

SS> Looking forward to the next spec.

from javaserverfaces-spec.

@edburns said:
owner

from javaserverfaces-spec.

@edburns said:
Here is a concrete proposal:

Several people have expressed interest in simplifying the clientId
generation scheme, as well as specifying the existing one we have.
First, let's specify what we have.

EXISTING ALGORITHM

Case 1: no user specified id anywhere.

<h:form>

<h:selectBooleanCheckbox value="#

{bean.checked}" />

</h:form>

In this case, component.getId() is null.

The CheckboxRenderer calls component.getClientId(). This is the
first time during the lifetime of the component instance that this
method is called. We search for an ancestor that is a
NamingContainer. We ask that NamingContanier for its clientId and
save it as the parentIds local variable. Because component.getId()
returns null, we set the clientId as parentIds +
context.getViewRoot().createUniqueId().

Finally, we call renderer.convertClientId(context, clientId);

This yields a clientId something like "_id0:_id1", without the quotes.

Case 1a: user specified id only on NamingContaner

<h:form id="form">

<h:selectBooleanCheckbox value="#{bean.checked}

" />

</h:form>

This yields a clientId something like "form:_id1", without the quotes.

Case 2: user specified id only on component

<h:form>

<h:selectBooleanCheckbox id="checkbox" value="#

{bean.checked}" />

</h:form>

The CheckboxRenderer calls component.getClientId(). This is the
first time during the lifetime of the component instance that this
method is called. We search for an ancestor that is a
NamingContainer. We ask that NamingContanier for its clientId and
save it as the parentIds local variable. Because component.getId()
returns non-null, we set the clientId as parentIds +
NamingContainer.SEPARATOR_CHAR + component.getId().

This yields a clientId something like "_id0:checkbox", without the
quotes.

Case 2a: user specified id everywhere

<h:form id="form">

<h:selectBooleanCheckbox id="checkbox" value="#{bean.checked}

" />

</h:form>

This yields a clientId something like "form:checkbox", without the
quotes.

PROBLEMS with EXISTING ALGORITHM

1. Not concretely specified. Easy to fix.

2. Page author has to execute the page to see what the generated
clientId is. That's silly.

PROPOSAL

Jacob has hinted at this, as well as Sean Schofield from the field.

• deprecate below method and keep the implementation the same:

public String Renderer.convertClientId(FacesContext context,
String clientId) {
if ((context == null) || (clientId == null))

{ throw new NullPointerException(); }
return (clientId);

}

• replace with below method, with this implementation

Renderer.convertClientId(FacesContext context, UIComponent component,
String clientId) {

String result = clientId;

if ((context == null) || (clientId == null) || (component == null)) { throw new NullPointerException(); }

String id = null, forceId = null;

if ((null != (forceId = component.getAttributes("forceId"))) &&
(null != (id = component.getId()))) {
if (forceId.equalsIgnoreCase("on") ||
forceId.equalsIgnoreCase("yes") ||
forceId.equalsIgnoreCase("true"))

{ result = id; }

}
return (result);
}

• add the "forceId" attribute as a non-required, expression enabled
  attribute on all standard components.

• Change UIComponent.getClientId() to call this new implementation of
  getClientId.

from javaserverfaces-spec.

@edburns said:
Note that if the user happens to use forceId inside of a UIData, they are hosing
themselves. I think we should allow them to do so, because, as the name of the
attribute says, this is a FORCE of the ID.

from javaserverfaces-spec.

@edburns said:
Created an attachment (id=20)
In-progress snapshot. UIDataTestcase fails.

from javaserverfaces-spec.

jhook said:
Created an attachment (id=22)
Passes Tests

from javaserverfaces-spec.

jhook said:
Created an attachment (id=23)
Still Passes Tests, but decided UIData should instead only index on new method instead of getClientId

from javaserverfaces-spec.

jhook said:
48-ClientIdSpecification-FINAL.zip

The diff and update files included in the zip are not correct, but the source
code is. The differences between the two change bundles is that FINAL pushes
clientId indexing off to 'getContainerClientId' instead of keeping it in
'getClientId'.

from javaserverfaces-spec.

jhook said:
Created an attachment (id=24)
Added Adam's Suggestion to have UIForm append its parent ContainerClientId

from javaserverfaces-spec.

@edburns said:
Thanks Jacob,

This one seems to work.

Trying the RI tests as well.

I'll check it in when everything verifies ok. Then I can close the issue!

Ed

from javaserverfaces-spec.

@edburns said:
fix checked in, spec updated.

from javaserverfaces-spec.

@edburns said:
Prepare to delete "spec" subcomponent.

from javaserverfaces-spec.

@edburns said:
Move all to 1.2

from javaserverfaces-spec.

@manfredriem said:
Closing resolved issue out

from javaserverfaces-spec.

File: 48-ClientIdSpecification-20050323.zip
Attached By: jhook

from javaserverfaces-spec.

File: 48-ClientIdSpecification-20050328.zip
Attached By: jhook

from javaserverfaces-spec.

File: 48-ClientIdSpecification-FINAL.zip
Attached By: jhook

from javaserverfaces-spec.

File: 48-ClientIdSpecification.tar.gz
Attached By: @edburns

from javaserverfaces-spec.

This issue was imported from java.net JIRA JAVASERVERFACES_SPEC_PUBLIC-48

from javaserverfaces-spec.

Marked as fixed on Thursday, March 4th 2010, 6:09:30 am

from javaserverfaces-spec.