> > 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. *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. *The purpose and soul of AOP is this, so let's not lock on implementation technical details. > Another rather big issue with the proposal is that it only applies to > UiBinder. How do you solve the same problem when you're not using UiBinder? > How about navigation in your app? (when you use History.newItem, or Places, > or Activities, or a third-party solution such as GWTP – OK, GWTP has its > own “security” feature) > UiBinder is a "framework" for creating widgets through a declarative syntax: it provides services that don't have to exist when you do things manually. When you use ClientBundle, you don't say "ClientBundle is a big issue because it doesn't handle css files that are not declared in it". It's pretty the same logic: either you use UiBinder and get it with its services, or you do the work manually a no one will blame you. > There's also the question of “what to do?” when a precondition is not met? > Should the widget not be created at all? should it be hidden? should it > matter to the user of the API? What if I'd prefer that my button be visible > but disabled? > *You don't have to think about what to do, it's the whole point of the feature*: a factory/manager will decide if it does raw GWT.create() (as today), or do more sophisticated logic: leaves the field null, does some css additions depending on the logged profile, ect... (you won't see it nor have to deal with it in the GWT core code), it's out of your control at this point. Naturally GWT will furnish a default factory that will continue to do raw GWT.create() as it did until now, but users could declare another factory in the module to override that behavior. Last, but not least, having such an API in GWT for widgets but nothing > related to communications (GWT-RPC, RequestFactory) is likely to lead to > applications that aren't actually secure, because developers have a false > sense of security provided by the API that just doesn't create their > widgets. > There's a plethora of security solutions for the java framework, users may choose to adopt JAAS, Spring security, server bundled security systems (this is another feature request: to use separate urls for methods to be able to intercept a method call and apply security constraints on it, it's another subject). Anyway, GWT is mainly the client side, the ecosystem is different in that part that is translated to js. There's no need for GWT to be responsible for the java language, as soon as we are on the java side, we're in another world that evolved many years before GWT and that has many many solutions for security. So maybe a product will raise someday to unify the declarations on the GWT side with the ones on the server, but that's definitely not a "required" thing So, my advice, as already given elsewhere, is: build what meets your > immediate need (either from scratch, or on top of UiBinder, or as a fork of > UiBinder), iterate on the API until you're satisfied, then (possibly) > iterate again to try to solve other use-cases. > If you forked UiBinder, try to come up with an extension API (preferably > not extending/reusing the generator, but rather providing extensions to it, > similar to how ResourceGenerator and CustomFieldSerializer allow modifying > the generator's behavior) on which you could build your security-oriented > feature and try to upstream the patch. > When and if your library got enough traction, then you can propose it's > made part of GWT core (and if the Steering Committee agrees, then you would > probably become its maintainer then, responsible for reviewing patches et > al.) > I'm already building it, and what I criticized in the bug is that I can't extend GWT easily (which is pretty problematic for an open source), that's why I asked to have methods access protected (rather than private and package protected) > Also, more technically-speaking, if you can build it as an annotation > processor (or possibly another kind of pre-processor) rather than a GWT > generator, it could be even better. > The idea is to separate concerns: so if annotations are "required" to be added direclty to the code, it will not be a good design. What is better is to make it possible to work without annotations (let's say a configuration file), and then add an annotation processor (that will generate that conf file) for those who want it. And anyway, the processing code is not written in GWT generator: the generator only calls code that will be executed at runtime : *instead of calling GWT.create(), it calls Factory.create(). *Such a simple replacement leaves space to control all the rest of the process in regular non generated code. -- 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/e65e7d9a-308f-4cb3-bf48-cb758172a99a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
