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
