On Saturday, May 24, 2014 11:24:05 AM UTC+2, Zied Hamdi OneView wrote: > > There's one big flaw with your proposal: it's not really “transparent”; >> the code “using” it has to know it's there (i.e. it's not AOP as you >> described it), because some @UiField could be 'null' or not visible >> (depending on actual implementation). >> I believe applying such a rule as “this widget might not be created at >> all” globally might solve some use cases, but opens other issues: e.g. how >> do I layout my screen depending on what's actually visible? >> > > As I mentioned it in the user group discussion: the fact that a field is > not created is a good thing since it permits to the user to early detect he > is trying to deal with a field that will not exist in certain conditions (I > called that a runtime-compiler: since it checks if there are potential bugs > at runtime). Furthermore, the field is not obliged ot be null, it can be > parametrized with a factory strategy (create non visible fields or create > them null): in any case it will be less hardcoded than the actual solution > that does raw GWT.create() without any possible choice. >
What I meant is that you're proposing changing the post-conditions of UiBinder from "every @UiField will be non-null after the call to createAndBindUi" to "any @UiField might be null", with the additional rule that whether the field will be null or not is not decided close to it (same class or "friend" class). So it's not "transparent" at all. The dev coding the "screen" will make assumptions about which @UiField might be null or which one would not, based on rules defined elsewhere in the app that it shouldn't have to deal with at the moment. Being explicit rather than implicit is a strength, even if it comes at the cost of more boilerplate (just having an additional annotation on the @UiField so the dev building the screen can tell the generator which ones it expects to be null under some conditions would be much better, and the generator would probably work more efficiently and produce better and faster code). > *By the way, how do you justify that you prefer a hardcoded solution to an > extensible one???* > > We both know it's not AOP, it can't be since there's no proxying > mechanism. But it works as if it was: *you can intercept the widget > creation and do decide if you want the default process to be executed > or/and yours.* > It's not just that, it's deciding whether it'll be created or not. There's a proposal already for plugging your own "factory" (https://code.google.com/p/google-web-toolkit/issues/detail?id=6151), but it doesn't change the post-conditions that those objects must be constructed (non-null). -- 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/bd98f392-ced8-488c-bd21-e35ff7f3c4be%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
