> > * 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" > * just Google *"authorization in gwt"* and you will see the problem doesn't have to be presented anymore, everyone knows it's not supported (it's definitely not an unknown problem Thomas) * It's a pitty you interpreted the request for making the library extendable for the community as a personal attack, I think it's legitimate to criticize code as long as it is constructive and can help have a better product
* there had been previous decisions related to the (non-)extensibility of > UiBinder > So the problem is known and requested > * 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) > You're right, the source code has a lot of scenarios and is difficult to understand, but it shouldn't mean "no one is allowed to use it apart GWT members", if we consent to use it despite its complexity and risk of having it changed, then we might have a good reason for that * 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. > > Ok, but this should be used as a friendly warning (to avoid trouble to people, saying "you shouldn't!"), not as a rigid law (giving sanctions to those who try to use it). I also think the only valid argument for a class to be non extensible is when it is not well specified (used as a temporary glue). As a consequence of this definition, a library cannot remain "not designed for extension" for a too long time. Because if it remains, it may lead to troubles even internally: the person who wrote it may quit, and the own members of the project may have trouble maintaining it. >From the moment a library/module is well feature specified, there's no need to "hide" parts of it from the public sight. Some parts may be extensible by design and ease the task of extending to user developers because it was thought to be extended there, but other parts that weren't originally thought as extensible might show they actually are... I'm trying to answer with "general rules" rather than specific points to keep the exchange on general cases, (I sent you a mail Thomas with my answer). -- 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/82684104-6578-4ee6-a1b4-357b5a526aa9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
