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.
On Saturday, May 24, 2014 6:32:32 AM UTC-5, Zied Hamdi OneView wrote:
>
> 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/78981d06-8a1a-4d4c-a9a7-7104cf054e8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
