On Wednesday, May 21, 2014 10:54:51 PM UTC+2, Goktug Gokdogan wrote: > > I looked at the issue tracker. > > To give you some background; UiBinder code base is quite complex, has so > many features that it is really hard to maintain. And usually touching one > place can easily break other places, so we usually try to prevent it to > grow organically by all different request flowing on us. > On the other side, in the issue tracker you were basically asking about > exposing a method from a class that is not even a public API in the first > place, which basically means "please start maintaining the API of some > internal implementation detail for my use case". The quick answer for that, > given the state of UiBinder, is 'no'; that is basically I think where > Thomas is coming from. >
Things that motivated my response: * asks for a solution to an unknown problem, rather than exposing the problem and trying to find the best solution (which I believe is not the one suggested in the issue) * worse, it's not even a request for "please make UiBinder extensible" (for whatever definition of "extensible"), it's a "please get out of my way so I can hack around" kind of request (I know the problem was –briefly, vaguely– discussed in the GWT user group, but wasn't reflected in the request on the issue tracker) * there had been previous decisions related to the (non-)extensibility of UiBinder * UiBinder internals have changed dramatically in the past (e.g. when switching to SafeHtmlTemplates, almost everything got rewritten; then when introducing UiRenderer, then when tentatively introducing Renderable; there was also an attempt to replace the use of getElementById with walking the DOM, eliminating the use of temporary IDs on elements, or even placeholder elements in some cases); opening them for public consumption is a no-go on those grounds (similar to what you were saying) * generators (and linkers) are not designed for extension; they're an implementation detail (as you said later in this thread). The public API is in the form of a base interface that you give to GWT.create(). There are exceptions, but they're well documented (CrossSiteIframeLinker, ResourceGenerator for ClientBundle, CustomFieldSerializer for RPC, and –but I'm not even sure– ServiceInterfaceProxyGenerator's createProxyCreator() method; that's all AFAICT) and specifically designed for extensibility without exposing (too much of) the internals. On the other hand, you can just start a thread in one of the discussion > groups, ask and brainstorm different extensibility options, evolve the idea > and propose a change in gwt-contributor group. That's probably the best way > to achieve your goal and sound reasonable to me. > +1 -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/fd03cfb6-05f7-4c39-b14d-e2ce34ca433b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
