[gwt-contrib] Re: Native Authorization in GWT
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(ClassT 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
[gwt-contrib] Add Object.clone as throwing implementation
Hi all, I would like to added a clone method to the java.lang.Object class in the GWT SDK which simply throws a CloneNotSupportedException. This makes it possible to implement the clone method in subclasses. See: https://gwt-review.googlesource.com/#/c/6035/ Daniel Kurka has already done a similar patch but without an adaption of GenerateJavaScriptAST.javahttps://gwt-review.googlesource.com/#/c/6035/1/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java class. My patch is already in the review system but still not approved. Thomas Broyer started with the review and asked me why the patch of Daniel was reverted. I think that Daniel simply forgot the changes in the GenerateJavaScriptAST.javahttps://gwt-review.googlesource.com/#/c/6035/1/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java . Some feedback would be nice :) BR Rocco -- 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/b2d067e8-f9c1-4fca-ab10-911e966b09f1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Add Object.clone as throwing implementation
I rolled the patch because it broke internal apps and it seemed to hard and not worthwhile to clean this up. I just imported the change and running some tests internally I get back once I can see what needs to be done. On Mon, May 26, 2014 at 11:37 AM, Rocco De Angelis rdeangeli...@gmail.comwrote: Hi all, I would like to added a clone method to the java.lang.Object class in the GWT SDK which simply throws a CloneNotSupportedException. This makes it possible to implement the clone method in subclasses. See: https://gwt-review.googlesource.com/#/c/6035/ Daniel Kurka has already done a similar patch but without an adaption of GenerateJavaScriptAST.javahttps://gwt-review.googlesource.com/#/c/6035/1/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java class. My patch is already in the review system but still not approved. Thomas Broyer started with the review and asked me why the patch of Daniel was reverted. I think that Daniel simply forgot the changes in the GenerateJavaScriptAST.javahttps://gwt-review.googlesource.com/#/c/6035/1/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java . Some feedback would be nice :) BR Rocco -- 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/b2d067e8-f9c1-4fca-ab10-911e966b09f1%40googlegroups.comhttps://groups.google.com/d/msgid/google-web-toolkit-contributors/b2d067e8-f9c1-4fca-ab10-911e966b09f1%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- Google Germany GmbH *Dienerstr. 12* *80331 München* Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Katherine Stephens -- 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/CALLujiovq8QnUqyF0a9wZU7ydzqFwpp0Yg72SibBaW7GKt%2BR%3Dg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Add Object.clone as throwing implementation
I wish Java's Object didn't implement Cloneable, seems crazy to implement an interface that you don't actually implement. -- 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/91bdbb10-44bf-4baf-953e-1a0a2c4b6576%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Add Object.clone as throwing implementation
The problem with implementing clone() at object is that it is an breaking change because of the rules for JSOs. JSOs are required to implement (and declare final) all Object methods because there is no dynamic dispatch. So having clone() at Object implies either implementing it in JavaScriptObject (and declare it final there), breaking all projects that have JSOs that implement clone() or required all JSOs to implement clone() again breaking all projects that have JSOs. On Mon, May 26, 2014 at 8:10 AM, 'Daniel Kurka' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: I rolled the patch because it broke internal apps and it seemed to hard and not worthwhile to clean this up. I just imported the change and running some tests internally I get back once I can see what needs to be done. On Mon, May 26, 2014 at 11:37 AM, Rocco De Angelis rdeangeli...@gmail.com wrote: Hi all, I would like to added a clone method to the java.lang.Object class in the GWT SDK which simply throws a CloneNotSupportedException. This makes it possible to implement the clone method in subclasses. See: https://gwt-review.googlesource.com/#/c/6035/ Daniel Kurka has already done a similar patch but without an adaption of GenerateJavaScriptAST.javahttps://gwt-review.googlesource.com/#/c/6035/1/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java class. My patch is already in the review system but still not approved. Thomas Broyer started with the review and asked me why the patch of Daniel was reverted. I think that Daniel simply forgot the changes in the GenerateJavaScriptAST.javahttps://gwt-review.googlesource.com/#/c/6035/1/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java . Some feedback would be nice :) BR Rocco -- 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/b2d067e8-f9c1-4fca-ab10-911e966b09f1%40googlegroups.comhttps://groups.google.com/d/msgid/google-web-toolkit-contributors/b2d067e8-f9c1-4fca-ab10-911e966b09f1%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- Google Germany GmbH *Dienerstr. 12* *80331 München* Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Katherine Stephens -- 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/CALLujiovq8QnUqyF0a9wZU7ydzqFwpp0Yg72SibBaW7GKt%2BR%3Dg%40mail.gmail.comhttps://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujiovq8QnUqyF0a9wZU7ydzqFwpp0Yg72SibBaW7GKt%2BR%3Dg%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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/CAC7T7gmdfh9AWd5%3D3bRNRzF_Os0bhKg1C4KPE0%2BiZtdnvNRQzA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
