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
--
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/9849403b-c47a-4f74-a5f8-1d507b33e052%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
