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