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 [email protected].
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.

Reply via email to