On Fri, Jul 2, 2010 at 6:20 PM, Ray Ryan <rj...@google.com> wrote:
>> This is absolutely not related to databinding, we just want to produce >> GUI builder for UiBinder. >> I think that tooling was specified as one of the reasons to use XML for >> GWT UI. So, this is on what I work now. :-) >> > > Well that makes a lot more sense. :-) > > It occurs to me that this could be a lot easier when we revive > r7816<http://code.google.com/p/google-web-toolkit/source/detail?r=7816>, > which I had to roll back > (r7858<http://code.google.com/p/google-web-toolkit/source/detail?spec=svn8346&r=7858>) > due to its naive handling of tables. If we make the paths the binder builds > part of its public api, you could have your map and we wouldn't have to > think as hard about hiding design time hooks from developers, or at least > not all of them. Certainly, you shouldn't make your changes before that code > comes back (and it really, really needs to come back). > Sorry, but I don't understand on what to look in r7816<http://code.google.com/p/google-web-toolkit/source/detail?r=7816> . Can you give hint how this can help in accessing widget objects and attribute values? If you speak about paths like "0/1/0", then I already have implementation for preparing/remembering them in XMLElement. ------------ public class XMLElement { //XXX <Instantiations private static final WeakHashMap<Element, String> wbpElementPaths = new WeakHashMap<Element, String>(); public static void rememberPathForElements(Document doc) { rememberPathForElements(doc.getDocumentElement(), "0"); } private static void rememberPathForElements(Element element, String path) { wbpElementPaths.put(element, path); NodeList childNodes = element.getChildNodes(); int elementIndex = 0; for (int i = 0; i < childNodes.getLength(); ++i) { Node childNode = childNodes.item(i); if (childNode.getNodeType() == Node.ELEMENT_NODE) { Element childElement = (Element) childNode; rememberPathForElements(childElement, path + "/" + elementIndex++); } } } public String getPath() { return wbpElementPaths.get(elem); } //XXX >Instantiations ------------ This method is called from UiBinderGenerator.generateOnce() ------- Document doc = getW3cDoc(logger, templatePath); //XXX <Instantiations XMLElement.rememberPathForElements(doc); //XXX >Instantiations uiBinderWriter.parseDocument(doc, binderPrintWriter); ------- > > In your original note you suggested: > > In method createAndBindUi() directly after creating each Widget instance >> (but before applying setX() methods) "wbpObjectHandler" is used to notify >> GWT Designer about new widget and its path in XML. GWT Designer bind Widget >> instance to model (using path) and also asks default values for all >> properties using getX() methods. > > > Why do you need this notice before the set calls? > We need default values for properties. This allows us to remove attribute (or method invocation in case of Java version of GWTD) when user tries to set for property same value as default. Easiest example - flipping "enabled" between true/false. Default value is "true", so only enabled="false" is written into XML. But if enabled="false" already existed in XML, and we ask isEnabled() after set calls, then it is "false" and we can not know that default value is "true". So, we need ask isEnabled() before setEnabled(false), i.e. directly after widget creation. Of course situation is trivial for "enabled" and standard GWT widgets and we could hardcode its default value. But we can not expect anything about custom widgets - some of them may be will use enabled "false" by default, or introduce new properties for which we also need to know value. At same time we need not only "default" values, but also "actual" values for properties/attributes. Not all setX() properties have corresponding getX() method. So, only reliable way for GWT Designer to know value is patch UiBinder generator to remember these values into map. > >> >>> >>>> 4. To allow quick updates of design canvas as user changes properties, >>>> without reloading GWT context each time, we should: >>>> 4.1. Generate Binder implementation class with new name each time, so >>>> be able to define each time new class in same ClassLoader. Right now >>>> we just add current time to the name of class. >>>> //XXX <Instantiations >>>> // generate class with new name each time, to allow refresh in >>>> same ClassLoader >>>> implName += "_wbp" + System.currentTimeMillis(); >>>> //XXX >Instantiations >>>> >>> >>> We could not do this with a timestamp, as it's important that the same >>> code always produce the same binary. Would appending an md5 sum to the class >>> name do the trick? >>> >> >> Well, I hope that now it is clear that nothing is going to be "produced" >> with such "design time" tweaks. >> At these modes generated code will be exactly same as it is now. >> > > But if we can avoid having alternative behavior at design time life is > simpler. Would check sums on the generated class names meet that need? > Probably yes. But I think that we should weight what is better/worse - quick check for design time or more-less time consuming calculation of check sum, plus having not-so-friendly class names in hosted mode. -- Konstantin Scheglov, Instantiations, Inc. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
