Thomas, I've long wondered how the UiBinder attachment process was done. I've read here before that temporary id's were used to swap elements in and out, and it made sense.
The UiBinder docs<https://developers.google.com/web-toolkit/doc/latest/DevGuideUiBinder#Lazy>also hint at this: > You know that when your ui is built, a getElementById() call is made for > each and every one of them. In a large page, that can add up. Since it's Saturday, and Googling found nothing for this enigma, I dug into the UiBinder source. Most of the meat is in UiBinderGenerator<https://code.google.com/p/google-web-toolkit/source/search?q=uibindergenerator&origq=uibindergenerator&btnG=Search+Trunk>and UiBinderWriter<https://code.google.com/p/google-web-toolkit/source/search?q=DOM_ID_HOLDER&origq=DOM_ID_HOLDER&btnG=Search+Trunk> : /** * Declare a variable that will be filled at runtime with a unique id, safe * for use as a dom element's id attribute. For {@code UiRenderer} based code, * elements corresponding to a ui:field, need and id initialized to a value * that depends on the {@code fieldName}. For all other cases let * {@code fieldName} be {@code null}. * * @param fieldName name of the field corresponding to this variable. * @return that variable's name. */ public String declareDomIdHolder(String fieldName) throws UnableToCompleteException { String domHolderName = "domId" + domId++; FieldWriter domField = fieldManager.registerField(FieldWriterType.DOM_ID_HOLDER, oracle.findType(String.class.getName()), domHolderName); if (isRenderer && fieldName != null) { domField.setInitializer("buildInnerId(\"" + fieldName + "\", uiId)"); } else { domField.setInitializer("com.google.gwt.dom.client.Document.get().createUniqueId()"); } return domHolderName; } > Given that I don't see id's in the finished browser elements, they must have been removed out, but I cannot be sure since the Run Time debugger does not allow peeking into the generator (rebinder) code. Not sure why UiBinder could not just hold on to the node reference of the insertion point, but browsers do funny things when you're ramming a ton of HTML in and you sometimes need to be asynchronous about it. Also, to the matter of using *id's*, you can, but not if the element has a * field* name too, however *id's* are now deprecated. The compiler code calls this an *OldSchoolId *in *UiBinderWriter*. Frankly I say never use an id in UiBinder, or other generated widget code, since id's are supposed to be * unique* and stamping out widgets with the same id just messes up your DOM. As to the debugId not working in GWT 2.4. One of my project uses debugId attributes in the ui.xml files extensively. When I tried to upgrade to 2.4, compile kept giving errors that "debugId" was not a legal attribute for various HTML elements. My assumption is that such attributes were not vetted before 2.4. I'm not sure why vetting is now done after five years, but the HTML spec allows anything you want in there and the browser is supposed to ignore invalid values, hence why debugId works in browsers. It would be nice if "debugId" could be a whitelisted attribute. Please if anyone else knows better how this work, do sing out. Sincerely, Joseph -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/kJyTouH4Pb8J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
