Native Authorization in GWT

[Zied Hamdi OneView]

Hi,

I want to talk about GWT authorizations to brainstorm an architecture that supports it natively. 

It's somehow surprising a framework that is in advance (adopted the Fog computing more than 5 years ago) doesn't provide a native support for security routines. Workarounds are naturally possible, but no real core solution is available, to specify how it should be done according to best practices and have developers immediately knowing what they do when they want to implement security in GWT.

There are some open sources that already propose solutions for this subject, they or developers who used them are naturally welcome to discuss the even ad odd points from their feedback. 

Before I started this discussion I made a tour on the available solutions  and I found all what I discovered either too intrusive (imposes its own architecture that might not be compatible with existing projects), or too superficial (means there is no central way of doing things).

With the evolution of IT, many thinkers brought new ways of solving problems. All problems can't be solved with one only pattern and overusing a pattern can lead to bad architectures (hardly maintainable code). 

AOP is an example of these best practice ideas that couldn't be overused. It decomposes a layer (in a n layer architecture) into different logically splitted layers. In AOP the interceptor knows about his host but the host doesn't event know the AOP exists. This is a good approach to separate concerns. The logger, the security some visual adjustments etc... can intercept the program without this latter knowing about them.

Another best practice pattern is the single access point: it is somehow related to the proxying because when all your program flow passes through a single object/method/facade, it is easy to intercept events and add logic.

The event oriented programming is a direct iteration on these two patterns, it states that a shared event bus can make the entire application connected and make it possible to plug itself on the program without impacting it.

I proposed a solution based on this approach to solve the security feature lack in GWT: an interception entry point to the creation of widgets to permit plugging into it and doing other interesting things GWT isn't obliged to be responsible of.

My proposal is here

https://code.google.com/p/google-web-toolkit/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Stars&groupby=&sort=&id=8727

A discussion already happened in the user forum too about the subject.

Your ideas and comments are welcome :)

[Thomas Broyer]

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?

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)

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?

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.

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.)

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.

[Zied Hamdi OneView]

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.

[Zied Hamdi OneView]

After doing the patch I can tell you the main points and benefits of the change:

To be able to do the job, I had to change the signature of AbstractFieldWriter.writeFieldDefinition() to make it aware of the context of the field (the document that declares the field)

com.google.gwt.uibinder.rebind.AbstractFieldWriter.writeFieldDefinition(IndentedWriter, TypeOracle, OwnerClass, FieldWriter, DesignTimeUtils, int, boolean)

I changed the hardcoded line

initializer = String.format("(%1$s) GWT.create(%1$s.class)", getQualifiedSourceName());

to an overridable method

initializer = writeInitilizerForField(ownerClass, field);

in my code I just overrided (this could be done in a GWT UiBinderFieldFactory class instead of my AuthManager)

protected String writeInitilizerForField(OwnerClass ownerClass, FieldWriter field) {

return String.format("(%1$s) fr.onevu.auth.client.common.patch.auth.AuthManager.create(%1$s.class, \"%2$s\", \"%3$s\")", getQualifiedSourceName(),

ownerClass.getOwnerType().getQualifiedSourceName(), field.getName());

}

knowing that in AuthManager I delegate the creation of the field to the concrete implementation of AuthorizationSpecifier that is by default in the module declaration

  <replace-with class="fr.onevu.auth.client.common.patch.auth.DefaultAuthorizationSpecifier">

    <when-type-is class="fr.onevu.auth.client.common.patch.auth.AuthorizationSpecifier"/>

  </replace-with>

This is not an invasive code at all and it doesn't break the architecture of the UiBinder. It might bring bugs if a panel is null and you assume it isn't, then for a first version, you might forbid returning null from the factory, but it's still a powerful feature will little change in the code. If I had to say it in one sentence it would be:

Giving the hand to the user to handle his widgets at creation instead of assuming to know what the user wants to do. 

[Zied Hamdi OneView]

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?

I've just realize what you meant Thomas, but I really don't agree, that's why I didn't get it :

• AOP can intercept methods to completely abort their call, it is still AOP (it is even surely what AOP is for). It can clearly be used to hide an element, that still doesn't mean the code that undergoes the AOP influence has to know there was an AOP code. It just has to sustain that possibility but it doesn't know from where it came.
  
• The "result hosting" code has anyway to deal with a field that doesn't exist or that is invisible. It has to either do it manually in traditional GWT, or have it done by another automatic/configurable process in what I'm proposing.

Behind the AOP there can be many possible solutions, GWT is not obliged to decide which to adopt, this can be handled as separate solutions: for example : 

• A map of profiles where each profile has a map of UiBinder name keys where it specifies in the value the look and visibility of fields (this way only fields that have special treatment are handled specifically)
  
• The inverse process: methods in the Widget mangaer interface to say isVisible(String uiWidget, String field), getStyles(String uiWidget, String field). Which allows a more abstract interface but can show performance issues on large applications
• a magic client factory that handles all this in a special library

Possibilities are open. The important thing is to be able to catch the moment a widget is about to be created to be able to have control on the decision. That's the whole point of this feature request

[Zied Hamdi OneView]

I forgot to say it's done and it works, I can submit the code under that bug id, but since the bug was closed I'm trying to justify why I think this feature is important

[Colin Alworth]

This seems to be a pretty quiet discussion so far, with mostly Zied responding to himself and Thomas’s one initial reply, but it is a holiday weekend here in the US, so that might be contributing to the lack of additional responses. I haven’t had the chance to even look at the initial proposal until this morning, but at a glance, I agree that it would be an interesting successor to uibinder or add-on to uibinder, but likely a poor modification of uibinder. I’m going to completely ignore the security aspect, as the ‘best practice’ is to ‘do it on the server’, and never ever trust the client. If you try trusting the client, you are better of just omitting the security to avoid any false sense of safety ;).

 - UiBinder is totally declarative - if it had the feature to wire in logical statements, we should equally have loop and conditional constructs.
 - Not everyone uses UiBinder, not everything can be done with UiBinder - use of this tool will be limited to users and use-cases that already are good fits for uibinder. Anything that is @UiField(provided=true)/@UiFactory may be ineligible (since they may be have some runtime decided type, so the UiBinder generator can’t see their moving target of setters), any cells or other non-uibinder-able ui components can’t work either.
 - I don’t see a full proposal anywhere, but from the issue at code.google.com it appears that the intention is to provide isAllowed and isReadOnly, and these cases only at initial widget creation, based on a String idPath, synchronously. Implications from here: All possible permissions that the app might ever access need to be loaded preemptively, and from that the server needs to know (and have sent) all possible paths that the app might have, permissions can’t change without the app being reloaded (either user gets errors from the server when permissions change while the app is running, or whole app should be refreshed when any permission change of current user, group, or other business logic changes), and permissions are never data-dependent (no need to ever check if the user ‘owns’ the given object, etc).
 - isAllowed is a bit of a terrifying prospect - either it is not being rendered as the specified type (i.e. all @UiFields must be Object and typed-checked at runtime), or they are left as null (and null checked for any .add, .setWidget that uses them, any add/setter called *on* them, and any {} reference made *to* them across all of uibinder internals). Again, not very declarative, since the type assumptions that can be made by users authoring the matching .java and .ui.xml need to assume that any of their declared code in xml might just be ignored and not available in .java.

Were I doing this, I’d go in another direction - don’t try to rewrite UiBinder into an imperative language, but instead make your own non-declarative xml->widgets that cover the required cases. Support conditions and looping, expect to call out to java (or better yet let java call back in to note that a state change has happened in permissions), and accept more data, such as the current model object, etc. No need to be accommodating to UiBinder or non-UiBinder, since this is a new tool entirely.

For fun, I made a aop-replacement tool, ostensibly for simple ui hints about permissions for access to things. The goal wasn’t to demonstrate that *all* AOP can be achieved with simpler constructs, but instead to show that much if it can, much of the time, with very little code. This tool was annotation based - define your own annotations and the logic that drives them, stick them on fields in the view, and ask the rules to run when any changes are made. For example, this annotation means ‘call .setVisible(currentUser.group == foo) on any widget with @OnlyVisibleTo(foo) on it. This is triggered by extending an interface and keying off of the view type and the model type - the resulting object has a ‘apply’ method that lets it take the view and the model, and applies the various rules declared in the view.
Annotation:
https://bitbucket.org/niloc132/generated-permissions/src/909e8cd41449c34ca2e3e659de921dc4221342e5/src/main/java/com/colinalworth/gwt/perms/sample/client/Sample.java?at=master
Sample that uses the annotation:
https://bitbucket.org/niloc132/generated-permissions/src/909e8cd41449c34ca2e3e659de921dc4221342e5/src/main/java/com/colinalworth/gwt/perms/sample/client/OnlyVisibleTo.java?at=master

I’m not proposing that this is the only way to solve this, but it is compatible with regular java views or UiBinder (just stick the annotations next to the @UiField). I also am not pushing this as a way to solve this sort of problem out of concerns for developers confusing the concept of hiding or disabling a widget with actual authorization, but am instead trying to move this toward a sort of binding tool, but for properties other than what editors normally work with (i.e. getter/setter against setValue/getValue).

If it helps, don’t look at this feedback as “we think UiBinder is perfect the way it is”, but instead as “UiBinder solves a specific use case, and is not designed to be extensible”. See this as encouragement to fork UiBinder and ultimately replace it, fixing its other warts along the way (all the hardcoded details you’ve observed, its ability to accept int[] but not double[], and exposing the same tools internally as externally for better extensibility). UiBinder is meant to be *only* create objects, attach objects, call setters, and then attach the results to the @UiFields. It has grown few stapled-on bits like ClientBundle, I18n, lazy panels. Stapling on more features won’t make it better. There are many who thing that UiBinder, like RequestFactory/AutoBeans and perhaps Editors should not have ever been added to gwt-user.jar itself, but instead been made third-party jars, included optionally to GWT.

[Thomas Broyer]

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).

[Zied Hamdi OneView]

Hi Colin,

Thanks for your reply. I'm now convinced you have a pretty stable vision of the rules of UiBinder, I wanted to let the community be able to have my modificatio that I find very valuable, that's why I was "spamming" yesterdy (sunday), before I leave this part of the project and get less reactive to submit the code.

 

- UiBinder is totally declarative - if it had the feature to wire in logical statements, we should equally have loop and conditional constructs. 

This depends on how far you can go when you say it's declarative: can it be declared partly in another file? because this is what I propose: that's why I don't want the user to have access to the object model but only to its identification (UiBinder class name, feidl name)

- Not everyone uses UiBinder, not everything can be done with UiBinder

Not everyone uses ClientBundle, people can write they css manually for example. This shouldn't be an argument to remove ClientBundle from GWT

- I don’t see a full proposal anywhere

So I started just asking to be able to override some methods (asked GWT to make them protected so we can override GWT classes, declare our own Generator and intercept calls on superclasses instead of copying all the access restricted classes : almost all the package)

- isAllowed and isVisible

 

were proposed methods only for the draft and for pedagogic reasons to understand the purpose). In reality theres's only one method in the GWT UiBinder: UiBinderWidgetFactory.create()

   <T extends Widget> T create(Class<T> widget, String uiBinder, String fieldName)

Notice I intentionally did that there's no access to the model instance so the information remains simple and clear (in a declarative roles file). This answers the first point and the one where you propose to have more dynamic information on what's elsewhere in the view. This is definitely unwanted. The purpose of this is only to build a complete UiBinder template with all possible combinations, and then filter what has to be shown for each profile.

Now, each developer will be able to provide his own UiBinderWidgetFactory and use UiBinder for the layout, and his own static declaration for the rules. Which are two distinct concepts that shoudn't be mixed together in annotations or templates. This is why I'm talking about AOP: this is a layer that souldn't be seen by the application.

Note: The meaning of @Provided doesn't interfere with this feature. these are two distinct things: if you decide to create you widget manually, don't expect us to jump infront to change whant you're doing. it's the expected behavior

Finally t's fair to me that if the user loggs out or changes his profile/roles, the application is reloaded. This doesn't happen sufficiently often in applications to justify special code treatments (it's 0.01% of the code in an app :). 

@Thomas: thanks for your answer and sorry for the amount of mails you found this morning :)

     - "every @UiField will be non-null after the call to createAndBindUi" to "any @UiField might be null"

I answered to this question by telling you that we can impose the retunrned Widget from the factory is not null (for the first versions). But the specification that says it hasn't to be null is not written in the stone. We might after all consider that if the user wants it to be null and decides it to be that way (in his own code), so he will have null. This only gives control to the user, it doesn't surprise him by changing what was there in his existing code (the default WidgetFactory will continue to create fields blindly). Only if a user decides he will furnish his own Widgetfactory and that he wants a field to be null under certain circumstances, he will get what he asked for. 

     - It's not just that, it's deciding whether it'll be created or not.

This can be checked and forbidden in the generated code, even if I think it's intrusive to oblige the user to have non null fields where he wants them null.

Finally, a per user (or/ per profile or/ per timezone or/ any) Widget personalization at creation is possible with this approach: it's the responsibility of the developer to separate authorizations from css styling but it's not the GWT responsibility anymore anyway. So even though the GWT WidgetFactory has only one method create(), the implementations might have other methods like

getStyles(), isToBeCreated(), isVisible(), isEnabled()

@Thomas : the bug you linked me to is interesting since it proposes a factory too, except that the factory is per UiBinder (which might be a good thing for performance) . The odd point I saw in answers is that it is aware of what widgets are in the component : It looses its "declarative" abstract tooling concept that way. But the spirit is indeed the same

In my proposition I have two arguments: (uiBinderFileName, fieldName), where they propose to attach a factory per UiBinder so they have only one parameter (or have it hardcoded as proposed in the comment N°5). My opinion is that separating factories can be complex for developers to manage and will tempt them to solve too many things in the factory, which is not the purpose)

Anyway I have the patch working, it's not just a feature proposal. If you want to take a look at it then tell me early as long as it's fresh in my mind. I'll attach what is behind the factory now (the declarative css and roles), so I might loose focus

 

[Zied Hamdi OneView]

I created an issue where I specify more clearly the change proposal: https://code.google.com/p/google-web-toolkit/issues/detail?id=8735

I'm getting this message:

 

I'm just unable to push the code for review

Tue May 27 12:28:27 2014

Pushing to https://gwt.googlesource.com/gwt

POST git-receive-pack (24854 bytes)

remote: Resolving deltas: 2% (1/34)

remote: Resolving deltas: 5% (2/34)

remote: Resolving deltas: 8% (3/34)

remote: Resolving deltas: 11% (4/34)

remote: Resolving deltas: 14% (5/34)

remote: Resolving deltas: 17% (6/34)

remote: Resolving deltas: 20% (7/34)

remote: Resolving deltas: 23% (8/34)

remote: Resolving deltas: 26% (9/34)

remote: Resolving deltas: 29% (10/34)

remote: Resolving deltas: 32% (11/34)

remote: Resolving deltas: 35% (12/34)

remote: Resolving deltas: 38% (13/34)

remote: Resolving deltas: 41% (14/34)

remote: Resolving deltas: 44% (15/34)

remote: Resolving deltas: 47% (16/34)

remote: Resolving deltas: 50% (17/34)

remote: Resolving deltas: 52% (18/34)

remote: Resolving deltas: 55% (19/34)

remote: Resolving deltas: 58% (20/34)

remote: Resolving deltas: 61% (21/34)

remote: Resolving deltas: 64% (22/34)

remote: Resolving deltas: 67% (23/34)

remote: Resolving deltas: 70% (24/34)

remote: Resolving deltas: 73% (25/34)

remote: Resolving deltas: 76% (26/34)

remote: Resolving deltas: 79% (27/34)

remote: Resolving deltas: 82% (28/34)

remote: Resolving deltas: 85% (29/34)

remote: Resolving deltas: 88% (30/34)

remote: Resolving deltas: 91% (31/34)

remote: Resolving deltas: 94% (32/34)

remote: Resolving deltas: 97% (33/34)

remote: Resolving deltas: 100% (34/34)

remote: Resolving deltas: 100% (34/34)

remote:

remote: Processing changes: refs: 1

remote: Processing changes: refs: 1, done

To https://gwt.googlesource.com/gwt

! [remote rejected] uibinderfactory -> master (prohibited by Gerrit)

error: failed to push some refs to 'https://gwt.googlesource.com/gwt' 

[Thomas Broyer]

You have to push to the special reference "refs/for/master" to create a review to be merged to the 'master' branch.

git push origin HEAD:refs/for/master

(replace HEAD with a local branch if you don't want to push the "current commit" but another reference/commit)

Note, you also have to "install" the hook that will generate the Change-Id line on commit; see http://www.gwtproject.org/makinggwtbetter.html#submittingpatches

If you hadn't installed it already, just amend your commit and the hook will run and modify your commit message appropriately.

Also keep in mind that 1 commit == 1 review !

[Zied Hamdi OneView]

Hi Thomas,

I decided to put the library as you suggested in a separate project, and to make it evolve to a state where it can be presented as an alternative to UiBinder. Here's the link, all unit tests pass. 

If any body wants to contribute, you're welcome

https://code.google.com/p/ui-binder-factory-proxy/

Le vendredi 23 mai 2014 14:59:35 UTC+1, Zied Hamdi OneView a écrit :