how much control do we have over component ids?
I have a related post about a huge table component's auto-generated id's bloating the html file size.
http://swforum.sun.com/jive/thread.jspa?threadID=111398
Now, what I'm wondering is how we can control the ids of components. Sure I can edit the id property in the property view, from say staticText6 to myText. But if that text component is nested in a table I get some sort of form1:table1:...:...:...:... monster of an id. So if I have many rows in my table, each with many fields, and each field having an additional <span> element with an even longer id property... do you see where I'm going with this?
Can I turn off ids? Is there an option for shorter ids? Are the ids even used at all? If I'm using a non-ajax component, what's the point of an id if I'm not using javascript to call getElementById?
Thanks.
[860 byte] By [
jeff.daily] at [2007-11-26 11:25:13]
# 1
One more additional comment. One of the features that Apache Tomahawk provides for all of its custom components is the ability to force the id of the component. Admittedly, I'm not exactly sure what that means. However, I would appreciate being able to force an id on the components provided by JSC.
For example, currently JSC doesn't allow any two components with the same id, no matter if they are siblings of each other, parent/child, cousin, etc. If you try giving a component an id that is already used, it appends an incremental number. What if I know I have a unique id that no other component uses anywhere on my page?
I would prefer that no matter what depth in the component tree that my component exists I would be able to force its id to "foo", such that during the render all of the extra colon-separated identifiers are omitted.
# 2
Your question got me wondering how necessary those ids are? So I modified the filter I posted earlier to investigate a related problem and it turns out that removing most of them doesn't break my app.
I think that anything that relies on javascript will break (autosubmit on change springs to mind)
Here's the link to the filter code:
http://forum.sun.com/jive/thread.jspa?threadID=110831&tstart=105
Here's the replacement method:
String magic="<input id=\"form1_hidden\" name=\"form1_hidden\" value=\"form1_hidden\" type=\"hidden\" />";
String holder="<input type=\"hidden\" id=\"form1:hiddenField1\" name=\"form1:hiddenField1\" value=\"enableSubmit\" />";
String idRegEx="id=\"form1:table\\d:[^_\"\\\r\n]*(\\.[^\"\\\r\n]*)*\"";
private void doAfterProcessing(ServletRequest request, ServletResponse response)
throws IOException, ServletException {
if (debug) log("HtmlManipulationFilter:DoAfterProcessing");
if(wrapper.getContentType().indexOf("text/html")!=-1) {
String res=wrapper.toString();
if(debug){
Pattern p = Pattern.compile(idRegEx);
Matcher m= p.matcher(res);
int x=0;
while(m.find(x)){
log("Regex matched:"+m.group());
x=m.end();
}
}
res=wrapper.toString().replaceAll(idRegEx, "");
// res=res.replace((CharSequence)"</form>", (CharSequence)magic+"\n</form>");
response.setContentLength(res.length());
out.write(res);
if (debug) {
int before = wrapper.toString().length();
int after = res.length();
float chaff=(0f+before-after)/before*100f;
log("Ouput without namespace:"+after);
log("Output with namespace:"+before);
log("Chaff:"+ chaff);}
} else
out.write(wrapper.toString());
out.close();
}
Here's my log output:
Ouput without namespace:193881|#]
Output with namespace:284679|#]
Chaff:31.89487|#]
HiddenFieldFilter processing time 1002|#]
This is a 35 row table with a dozen or so columns
If you tinker with the regex so that it removes the magic field you'll need to replace it by uncommenting the relevant line in the above method.
My dev server was able to remove 90 odd kB of output in 1 second (and logged each removal. Ain't tested my live server yet but this is a worthwhile saving in my environment as my average user can transfer 9 - 14 kB in a second (on a good day!). It's also possible to configure filtering on a per page basis so I can eliminate the overhead where it's not needed. I still need to see if gzip combined with filtering results in a net gain or loss.
Oh and i know this is the wrong layer to attack this problem, but until Sun say something about it it's all we can do!
Please let me know if you get any further with this optimization...
Regards
Y
# 3
I've researched the ID issue a bit further and came across this article.
http://java.sun.com/developer/technicalArticles/J2EE/jsf_12/
It's a summary of the new features with JSF 1.2. It looks as though the topic "Ability to Turn Off Generation of Component Client IDs" covers some of what we are experiencing in JSC.
http://java.sun.com/developer/technicalArticles/J2EE/jsf_12/#clientID
Unfortunately, from my experience I haven't found a way to use these new features in JSC. Our development team chose JSC for its visual design elements, but our component needs are pushing us towards Java 1.5/JSF1.2.
