On Friday, May 23, 2014 4:41:28 AM UTC+2, Zied Hamdi OneView wrote: > > * 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) >
The issue of "authorization in gwt" is not unknown (BTW, I don't understand how it's a "problem" and even less how it's a problem "in GWT"; GWT doesn't provide tools specifically for that, but that doesn't mean it cannot be done, just that you have to do it yourself, or with third-party libraries such as AcrIS <https://code.google.com/p/acris/wiki/SecurityClient> – I never used it, just stumbled on it a few times). What I'm saying is that the issue doesn't state the problem you're trying to solve; it just says “I wanted to implement roles in my GWT application.” This is not enough of a problem description to me (just look back at the discussion with Jens to understand what I mean; different people have different expectations of what "roles" are and what they imply). > > * It's a pitty you interpreted the request for making the library > extendable for the community as a personal attack, > I didn't! 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 > Yes, and the decisions were that @UiField(provided=true), @UiFactory, @UiConstructor and @UiChild were enough to support most use cases, and others could either be built on top of them or just not use UiBinder (at least for the cases where it doesn't fit) > * 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", > It's not even "apart from GWT members". No one should try to re-use it (and I'm purposefully using "re-use" here). Everyone is free to fork it though. This doesn't apply only to UiBinder. Forks have a cost, but it's a cost for the maintainer of the fork, not for the maintainers of the original project (and by extension, the whole community: because that means time spent maintaining backwards-compatibility of some obscure APIs used by only a couple users cannot be spent on other things that would benefit everyone). And I'm not saying that specifically with my "GWT maintainer" hat; I also have to live with these decisions as a user of GWT; it's sometimes frustrating, but I believe it's the right thing to do. At work, I started bending RequestFactory to specific needs it wasn't designed for, and I had to maintain a fork and contribute patches. The patches took years (literally) to be accepted, and some of them only because I now am the maintainer of RequestFactory (co-maintainer, with Manolo). > if we consent to use it despite its complexity and risk of having it > changed, then we might have a good reason for that > …and you could then just fork the code. I'm not talking about forking GWT, but, as you did, copy the classes in your own package and build your own enhanced version of UiBinder. The cost wouldn't be much different (trade the cost of having to adapt to breaking changes in new versions of GWT which can prevent you from upgrading, with the cost of integrating those changes into your fork at the time you choose to do it and without preventing you from upgrading GWT to benefit from other features and bug fixes). I believe (and I think it's the general feeling within the GWT team) those kind of forks are healthy; “duplication is far cheaper than the wrong abstraction”. -- 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/88602253-ac15-4925-b641-9e9fb3542d4a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
