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. *
Le vendredi 23 mai 2014 14:59:35 UTC+1, Zied Hamdi OneView a écrit :
>
> 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>
>
> 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<https://groups.google.com/forum/#!topic/google-web-toolkit/wk9a3mCRliY>already
> happened in the user forum too about the subject.
>
> Your ideas and comments are welcome :)
>
>
--
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/eae201a2-a135-4ef4-82cf-aa20731aadaa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
