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 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/eae201a2-a135-4ef4-82cf-aa20731aadaa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
