On Thu, Jul 1, 2010 at 3:55 PM, Konstantin Scheglov < konstantin.scheg...@gmail.com> wrote:
> > > What does WBP stand for? >> > > WBP is acronym for "WindowBuilder > Pro<http://www.instantiations.com/windowbuilder/>" > - set of plugins for Eclipse for WYSIWYG development of GUI for Swing, SWT, > RCP, XWT and GWT. > > > >> >>> Path in XML is "/" separated string of indexes. >>> For example in >>> <ui:UiBinder> >>> <ui:style/> >>> <g:FlowPanel styleName="{style.panel}"> >>> <g:Button text="New Button"/> >>> </g:FlowPanel> >>> </ui:UiBinder> >>> >>> "0/1" is FlowPanel >>> "0/1/0" is Button >>> >> >> This doesn't sound like a tooling hook, it sounds like a data binding >> framework, and a very run time one — not really how we like to do things, >> and not how we're gearing up to write our own data binding support this >> month. >> >> What is the model object we're talking about? Does GWT designer impose a >> particular architecture on its users, or is it an implementation detail of >> designer itself? >> > > GWT Designer <http://www.instantiations.com/gwtdesigner/> is tool for > WYSIWYG building of GWT UI, which development I lead at Instantiations. > Its latest release works only with Java source for GWT, but now I work on > UiBinder support too and many things already > work<http://dl.dropbox.com/u/76691/Eclipse/images/Screenshot-20100701-232651.png> > . > > 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). 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? > > > >> >> I'd be a lot more comfortable with hooks that happen at code generation >> time, e.g. to allow you to navigate the model binder builds before things >> get written to disk. >> > > Note, that nothing is going to be written on disk, because we speak only > about design time. > For design time we use tweaked "dev" code, what we call "hosted mode > support", which we use to create CompilingClassLoader. And for design time > we don't write any output of generators on disk. Users don't need this at > design time. > And any such "wbp" related code (note, this is just current name, we > could use for example "designTime" prefix) will be generated only if > Beans.isDesignTime() is set to true. Nothing will be generated for "dev > mode" or "deploy mode". > > > >> >>> 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? > > > -- > Konstantin Scheglov, > Instantiations, Inc. > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
