[gwt-contrib] Re: Native Authorization in GWT
Hi Thomas, I decided to put the library as you suggested in a separate project, and to make it evolve to a state where it can be presented as an alternative to UiBinder. Here's the link, all unit tests pass. If any body wants to contribute, you're welcome https://code.google.com/p/ui-binder-factory-proxy/ 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 herehttps://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727 https://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727 A discussionhttps://groups.google.com/forum/#!topic/google-web-toolkit/wk9a3mCRliYalready 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 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/95ae19ac-c132-4938-87ba-dab37d5c1796%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Native Authorization in GWT
I created an issuehttps://code.google.com/p/google-web-toolkit/issues/detail?id=8735where I specify more clearly the change proposal: https://code.google.com/p/google-web-toolkit/issues/detail?id=8735 I'm getting this message: I'm just unable to push the code for review Tue May 27 12:28:27 2014 Pushing to https://gwt.googlesource.com/gwt POST git-receive-pack (24854 bytes) remote: Resolving deltas: 2% (1/34) remote: Resolving deltas: 5% (2/34) remote: Resolving deltas: 8% (3/34) remote: Resolving deltas: 11% (4/34) remote: Resolving deltas: 14% (5/34) remote: Resolving deltas: 17% (6/34) remote: Resolving deltas: 20% (7/34) remote: Resolving deltas: 23% (8/34) remote: Resolving deltas: 26% (9/34) remote: Resolving deltas: 29% (10/34) remote: Resolving deltas: 32% (11/34) remote: Resolving deltas: 35% (12/34) remote: Resolving deltas: 38% (13/34) remote: Resolving deltas: 41% (14/34) remote: Resolving deltas: 44% (15/34) remote: Resolving deltas: 47% (16/34) remote: Resolving deltas: 50% (17/34) remote: Resolving deltas: 52% (18/34) remote: Resolving deltas: 55% (19/34) remote: Resolving deltas: 58% (20/34) remote: Resolving deltas: 61% (21/34) remote: Resolving deltas: 64% (22/34) remote: Resolving deltas: 67% (23/34) remote: Resolving deltas: 70% (24/34) remote: Resolving deltas: 73% (25/34) remote: Resolving deltas: 76% (26/34) remote: Resolving deltas: 79% (27/34) remote: Resolving deltas: 82% (28/34) remote: Resolving deltas: 85% (29/34) remote: Resolving deltas: 88% (30/34) remote: Resolving deltas: 91% (31/34) remote: Resolving deltas: 94% (32/34) remote: Resolving deltas: 97% (33/34) remote: Resolving deltas: 100% (34/34) remote: Resolving deltas: 100% (34/34) remote: remote: Processing changes: refs: 1 remote: Processing changes: refs: 1, done To https://gwt.googlesource.com/gwt ! [remote rejected] uibinderfactory - master (prohibited by Gerrit) error: failed to push some refs to 'https://gwt.googlesource.com/gwt' -- 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/3a667318-c74a-4178-bec7-62165643293e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[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] Re: Native Authorization in GWT
There's one big flaw with your proposal: it's not really “transparent”; the code “using” it has to know it's there (i.e. it's not AOP as you described it), because some @UiField could be 'null' or not visible (depending on actual implementation). I believe applying such a rule as “this widget might not be created at all” globally might solve some use cases, but opens other issues: e.g. how do I layout my screen depending on what's actually visible? I've just realize what you meant Thomas, but I really don't agree, that's why I didn't get it : - AOP can intercept methods to completely abort their call, it is still AOP (it is even surely what AOP is for). It can clearly be used to hide an element, that still doesn't mean the code that undergoes the AOP influence has to know there was an AOP code. It just has to sustain that possibility but it doesn't know from where it came. - The result hosting code has anyway to deal with a field that doesn't exist or that is invisible. It has to either do it manually in traditional GWT, or have it done by another automatic/configurable process in what I'm proposing. Behind the AOP there can be many possible solutions, GWT is not obliged to decide which to adopt, this can be handled as separate solutions: for example : - A map of profiles where each profile has a map of UiBinder name keys where it specifies in the value the look and visibility of fields (this way only fields that have special treatment are handled specifically) - The inverse process: methods in the Widget mangaer interface to say isVisible(String uiWidget, String field), getStyles(String uiWidget, String field). Which allows a more abstract interface but can show performance issues on large applications - a magic client factory that handles all this in a special library Possibilities are open. The important thing is to be able to catch the moment a widget is about to be created to be able to have control on the decision. That's the whole point of this feature request -- 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/ae8635a1-371a-4b5d-9d9f-947b110f518b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Native Authorization in GWT
I forgot to say it's done and it works, I can submit the code under that bug id, but since the bug was closed I'm trying to justify why I think this feature is important -- 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/cb748642-c029-41fa-a807-853a1c71eb99%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Native Authorization in GWT
There's one big flaw with your proposal: it's not really “transparent”; the code “using” it has to know it's there (i.e. it's not AOP as you described it), because some @UiField could be 'null' or not visible (depending on actual implementation). I believe applying such a rule as “this widget might not be created at all” globally might solve some use cases, but opens other issues: e.g. how do I layout my screen depending on what's actually visible? As I mentioned it in the user group discussion: the fact that a field is not created is a good thing since it permits to the user to early detect he is trying to deal with a field that will not exist in certain conditions (I called that a runtime-compiler: since it checks if there are potential bugs at runtime). Furthermore, the field is not obliged ot be null, it can be parametrized with a factory strategy (create non visible fields or create them null): in any case it will be less hardcoded than the actual solution that does raw GWT.create() without any possible choice. *By the way, how do you justify that you prefer a hardcoded solution to an extensible one???* We both know it's not AOP, it can't be since there's no proxying mechanism. But it works as if it was: *you can intercept the widget creation and do decide if you want the default process to be executed or/and yours. *The purpose and soul of AOP is this, so let's not lock on implementation technical details. Another rather big issue with the proposal is that it only applies to UiBinder. How do you solve the same problem when you're not using UiBinder? How about navigation in your app? (when you use History.newItem, or Places, or Activities, or a third-party solution such as GWTP – OK, GWTP has its own “security” feature) UiBinder is a framework for creating widgets through a declarative syntax: it provides services that don't have to exist when you do things manually. When you use ClientBundle, you don't say ClientBundle is a big issue because it doesn't handle css files that are not declared in it. It's pretty the same logic: either you use UiBinder and get it with its services, or you do the work manually a no one will blame you. There's also the question of “what to do?” when a precondition is not met? Should the widget not be created at all? should it be hidden? should it matter to the user of the API? What if I'd prefer that my button be visible but disabled? *You don't have to think about what to do, it's the whole point of the feature*: a factory/manager will decide if it does raw GWT.create() (as today), or do more sophisticated logic: leaves the field null, does some css additions depending on the logged profile, ect... (you won't see it nor have to deal with it in the GWT core code), it's out of your control at this point. Naturally GWT will furnish a default factory that will continue to do raw GWT.create() as it did until now, but users could declare another factory in the module to override that behavior. Last, but not least, having such an API in GWT for widgets but nothing related to communications (GWT-RPC, RequestFactory) is likely to lead to applications that aren't actually secure, because developers have a false sense of security provided by the API that just doesn't create their widgets. There's a plethora of security solutions for the java framework, users may choose to adopt JAAS, Spring security, server bundled security systems (this is another feature request: to use separate urls for methods to be able to intercept a method call and apply security constraints on it, it's another subject). Anyway, GWT is mainly the client side, the ecosystem is different in that part that is translated to js. There's no need for GWT to be responsible for the java language, as soon as we are on the java side, we're in another world that evolved many years before GWT and that has many many solutions for security. So maybe a product will raise someday to unify the declarations on the GWT side with the ones on the server, but that's definitely not a required thing So, my advice, as already given elsewhere, is: build what meets your immediate need (either from scratch, or on top of UiBinder, or as a fork of UiBinder), iterate on the API until you're satisfied, then (possibly) iterate again to try to solve other use-cases. If you forked UiBinder, try to come up with an extension API (preferably not extending/reusing the generator, but rather providing extensions to it, similar to how ResourceGenerator and CustomFieldSerializer allow modifying the generator's behavior) on which you could build your security-oriented feature and try to upstream the patch. When and if your library got enough traction, then you can propose it's made part of GWT core (and if the Steering Committee agrees, then you would probably become its maintainer then, responsible for reviewing patches et al.) I'm
[gwt-contrib] Re: Native Authorization in GWT
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
herehttps://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727
https://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727
A
discussionhttps://groups.google.com/forum/#!topic/google-web-toolkit/wk9a3mCRliYalready
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
[gwt-contrib] Native Authorization in GWT
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 herehttps://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727 https://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727 A discussionhttps://groups.google.com/forum/#!topic/google-web-toolkit/wk9a3mCRliYalready 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 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/73ffbe2a-e7fe-4be8-9e48-32631af6203b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: who discusses the next features and adopts feature requests?
Hi all, I created this post as I said because I was wondering about the evolution of the process of feature proposal acceptance. This was triggered by a feature proposal I made that was rejected, but it was only a trigger. So to avoid changing the subject and talking about why my proposal was rejected and forgetting to talk about: what is the best way to accept reject proposals, I created another discussion for the rejected feature request herehttps://groups.google.com/forum/#!topic/google-web-toolkit-contributors/Y_Cu_Nqzxv4 We stopped at my proposal to have a GWT official fork for incubating features (explaining that if any other entity than GWT does the fork, it won't be accepted by the community) -- 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/49603644-b215-4de7-b0b9-45c424523f14%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: who discusses the next features and adopts feature requests?
*IMHO it is totally irrelevant if a package is named internal or not. If the API in that package is public then its public and if that API is useful it will be used no matter what. * I don't agree with you on this point: when the team designs a solution, they know if it's a solid architecture or if they didn't have time to think about it and there a re big chances these APIs will change drastically in future versions. Sometimes it is also because they're applying a new idea and they don't know how it will evolve (which axis will be the leading axis). So naming packages that are well designed the same way as packages that aren't is a loss of information. User developers will feel they have been betrayed if they build a big solution on an API that disappears on the next release or completely mutates in a way that they have to rewrite their soft from ground. So unless all GWT packages are well and maturely thought an no package is done only to solve a problem very specifically then taken the time to rethink (which I doubt). Loosing this information (or not communicating it is definitely a risky choice) *Actually I think the best way to let people try features that are not in GWT trunk is to create a GWT fork at Github and let people know about it. * Ok, but you know humans: each person will want himself to be glorified, and a person wouldn't like his efforts to be stolen and attributed to another person who just forked GWT. That's why, unless the GWT team says: here's an official Github fork to post your ideas (the part of: let people know about it). The GWT team might specify it's a fork made by the community for the community : the fact it is somehow certified as the official GWT fork changes a lot of things in comparison to if I said to everyone: it's My Fork come and put your effort in it, I will be rewarded for your efforts. As I started this discussion by saying that if everybody starts forking GWT we will loose the synergy, and proposed to brainstorm on the procedure to avoid that, it's no surprise that when you argue that everyone should fork GWT and make people know about it I will not agree :) -- 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/d612fdc0-dde1-4796-83e6-fb8d7103cc18%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: who discusses the next features and adopts feature requests?
There are a lot of working collaborative models out there, with more or less top control: my best examples are stackoverflow and wikipedia. There are disadvantages in their solution but it works. I know source code is not as granular as a wikipedia article, or a stackoverflow question. But you can already see in stackoverflow that if a person asks an alredy asked question his question is kind of 'rejected' (unvoted, marked as duplicate or unanswered). So people are aware and fight dependencies in a quite less firmly tighted platform than our target (in source code you can see dependencies a lot better than in a question forum) Even Google organizes the Google summer of Code where students contribute to different open source projects, but at the same time in an centrally organized manner (so good profiles can be detected and given wider responsibilities)... the same could apply for this fork -- 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/0993daeb-4c30-44c4-8fdf-701413d9b058%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: who discusses the next features and adopts feature requests?
* asks for a solution to an unknown problem, rather than exposing the problem and trying to find the best solution (which I believe is not the one suggested in the issue) * worse, it's not even a request for please make UiBinder extensible (for whatever definition of extensible), it's a please get out of my way so I can hack around * just Google *authorization in gwt* and you will see the problem doesn't have to be presented anymore, everyone knows it's not supported (it's definitely not an unknown problem Thomas) * It's a pitty you interpreted the request for making the library extendable for the community as a personal attack, I think it's legitimate to criticize code as long as it is constructive and can help have a better product * there had been previous decisions related to the (non-)extensibility of UiBinder So the problem is known and requested * UiBinder internals have changed dramatically in the past (e.g. when switching to SafeHtmlTemplates, almost everything got rewritten; then when introducing UiRenderer, then when tentatively introducing Renderable; there was also an attempt to replace the use of getElementById with walking the DOM, eliminating the use of temporary IDs on elements, or even placeholder elements in some cases); opening them for public consumption is a no-go on those grounds (similar to what you were saying) You're right, the source code has a lot of scenarios and is difficult to understand, but it shouldn't mean no one is allowed to use it apart GWT members, if we consent to use it despite its complexity and risk of having it changed, then we might have a good reason for that * generators (and linkers) are not designed for extension; they're an implementation detail (as you said later in this thread). The public API is in the form of a base interface that you give to GWT.create(). There are exceptions, but they're well documented (CrossSiteIframeLinker, ResourceGenerator for ClientBundle, CustomFieldSerializer for RPC, and –but I'm not even sure– ServiceInterfaceProxyGenerator's createProxyCreator() method; that's all AFAICT) and specifically designed for extensibility without exposing (too much of) the internals. Ok, but this should be used as a friendly warning (to avoid trouble to people, saying you shouldn't!), not as a rigid law (giving sanctions to those who try to use it). I also think the only valid argument for a class to be non extensible is when it is not well specified (used as a temporary glue). As a consequence of this definition, a library cannot remain not designed for extension for a too long time. Because if it remains, it may lead to troubles even internally: the person who wrote it may quit, and the own members of the project may have trouble maintaining it. From the moment a library/module is well feature specified, there's no need to hide parts of it from the public sight. Some parts may be extensible by design and ease the task of extending to user developers because it was thought to be extended there, but other parts that weren't originally thought as extensible might show they actually are... I'm trying to answer with general rules rather than specific points to keep the exchange on general cases, (I sent you a mail Thomas with my answer). -- 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/82684104-6578-4ee6-a1b4-357b5a526aa9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] who discusses the next features and adopts feature requests?
Hi, I had the experience of wanting to contribute to GWT with a new featurehttps://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727, but I received kind of a rigid answer: we won't adopt that, it was designed otherwise. So I'm wondering who decides on the design, since this if decisions are rigid there is a risk that the community will fork GWT and have different variants (which is naturally bad in essence because the energy will be split on the different projects). I think this is an important questions to solve: who decides on priorities? For my concrete example: there's no standard solution for authorizations in GWT, addressing the problem is definitely a subject that interests the whole community. I proposed a draft solution that is born dead. So - where can we discuss the design of a solution to be adopted? - do we really have to wait until there are thousands of favorites on a bug to start thinking about it - other platforms adopted solutions for (logging, aop, security, code organisation, ect...) if something exists and works on other platforms, isn't that an additional indicator that the feature is valuable and that it should be addressed in GWT too? Your 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 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/ba191aeb-9c88-4fcb-a1a3-dae0d2963ac0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: who discusses the next features and adopts feature requests?
Hi Daniel, Thanks for your clear answer. From what I understood, profiles are somehow validated through they contributions quality, and that gives a weight to their opinions if they propose new ideas?. Maybe it's not a formal model but it's probably the way it works. This seams quite wise, I'd only add into consideration the fact that (in my opinion) the majority of contributions come from a concrete need for their project, after solving the problem in the core technology, the person wants the patch to become public so he/she can profit from upgrades without having to maintain their patch to it (usually the company agrees with the decision to share the code for that reason). So only a small part of the users will contribute, and if their propositions are rejected too fast, you won't be able to evaluate the quality of the contribution because the person won't come back before another bug. That's why I think there should be a kind of idea hunter mechanism (that could be driven by the community itself, without the need for Google to allocate resources for that). People could send their patches to a parallel version where the community could vote for a feature to become part of the core. This would raise an indicator that the feature is wanted and trigger a reflection on how to design the solution. I'm only sharing ideas live, kind of brainstorming, there might be illogical things in what I'm proposing, but I think the subject is worth it. p.s: I think the strength of Google was in its recruitment strategy, that made it grow without loosing efficiency. A kind of similar solution is needed for GWT as an independent open source in my opinion... Le mercredi 21 mai 2014 18:11:44 UTC+1, Zied Hamdi OneView a écrit : Hi, I had the experience of wanting to contribute to GWT with a new featurehttps://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727, but I received kind of a rigid answer: we won't adopt that, it was designed otherwise. So I'm wondering who decides on the design, since this if decisions are rigid there is a risk that the community will fork GWT and have different variants (which is naturally bad in essence because the energy will be split on the different projects). I think this is an important questions to solve: who decides on priorities? For my concrete example: there's no standard solution for authorizations in GWT, addressing the problem is definitely a subject that interests the whole community. I proposed a draft solution that is born dead. So - where can we discuss the design of a solution to be adopted? - do we really have to wait until there are thousands of favorites on a bug to start thinking about it - other platforms adopted solutions for (logging, aop, security, code organisation, ect...) if something exists and works on other platforms, isn't that an additional indicator that the feature is valuable and that it should be addressed in GWT too? Your 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 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/71448d97-e71e-4a77-8e4d-af2da6f01b1a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: who discusses the next features and adopts feature requests?
Hi Goktug and John, Thanks for your answers, here's what I can say to be more explicit in my thoughts @Goktug you were basically asking about exposing a method from a class that is not even a public API in the first place, which basically means please start maintaining the API of some internal implementation detail for my use case Usually, internal APIs are in a package named internal because they are subject to change and the architecture is still not clear (the first iterations usually). I experienced this in the years 2005 (already at that time) when I was at Omondo and we needed to develop plugin features even using those cutting edge libraries (at our own risks of rewriting at the next eclipse version). The libraries were marked internal but were still designed well enough so we were able to use them (that's why I mentioned that the protected access should be the default one in open sources). Naturally everything was not blue sky at that time, but it was great to be able to know that we take risks by using those libraries (marked internal), and at the same time to be able to use them (at the same risks as the eclipse team itself). So to mark a library as subject to change or only for experts you may write it explicitely in the docs, but I don't see the point of overprotecting the developers by forbidding them to enter the zone, or considering it's too hard and dangerous for them. I pointed the consequences of forbidding zones at the first mail here : saying it leads to forking the project. That's definitely not a good strategy to get people consider them selves at home. I prefer warning but letting people do at their own risks, you might be surprised of what the community can do (and as I said, it's completely valid to refuse to treat bugs on a part that is marked as subject to change). So that's why I proposed to make the necessary methods (not one method, I was talking about roughly 20 classes) accessible from the outside to permit extending GWT in that part (even as independent libraries) without having to fork GWT (or extract those too restricted classes) @John in any community project, whoever cares about a feature the most is the one that designs it, convinces others it is worth including, and implements it I agree with you, I didn't know how it works inside the GWT team, that's why I supposed the most votes features are given more importance. Anyway, what I was asking in that bug was exactly : to permit access to the class members so I can do a lib that relies on it without having to fork a part of GWT. //- We left the principal subject and focused on a specific bug, I think it's good to do this but to a certain extent. as long as we don't loose focus on the subject of the post, which is not that tightly related to that bug, even if it was triggered by it. The subject is more procedural than technical I was thinking about Ubuntu that raises the xx.04 versions that are maintainable for some years and the xx.10 versions that are more experimental. Having a similar model for GWT with the community releases and the incubator releases might be an answer to permit both a stable and head and a dynamic community move?... I wouldn't like to reinvent the wheel, I'm wondering what can be done to allow the community to feel like home on the GWT project. Ideally, people should be able to try patches independently (somehow as plugins) and the GWT team can have visibility on the most popular patches that might be candidates to the head version (or are worth thinking on how to specify them cleanly). This would imply having versions of the GWT incubator (not a constantly moving trunk) and a system for dependency control (gradle, maven, ant) between both module-module and module-GWT builds. A similar system was used for the browser plugins, which showed to be complicated, especially when modules depended on each other (an app the uses flash that is compatible with a certain version of the browser) Take as an example what I'm adopting now (for the bug I submitted): I prefer to change the GWT core code locally and maintain my code working on the core code each time a pull a new version than copying the GWT classes to my own library where I will have to do manual comparing of which class became what in the next GWT version (loosing the git history of the files). -- 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/86ef2834-ca05-43a9-9402-91539bd03f40%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Errors in eclipse on gwt-user after cloning git
Hi Gwt friends :) I wanted to start contributing to GWT, so I followed the instructions until I arrived to the point of using my eclipse. There I have the following errors (and since I don't want to change code that I don't want to submit I'm kind of stuck in what to do now?). The errors are the following: Description Resource Path Location Type The type java.util.Mapjava.lang.String,java.lang.Integer cannot be used here BaseFooProxy.java /gwt-user/core/test/com/google/web/bindery/requestfactory/shared line 79 Annotation Problem (Java 6 processor) The type java.util.Mapjava.lang.Integer,com.google.web.bindery.requestfactory.shared.SimpleBarProxy cannot be used here BaseFooProxy.java /gwt-user/core/test/com/google/web/bindery/requestfactory/shared line 81 Annotation Problem (Java 6 processor) The type java.util.Mapcom.google.web.bindery.requestfactory.shared.SimpleBarProxy,java.lang.Integer cannot be used here BaseFooProxy.java /gwt-user/core/test/com/google/web/bindery/requestfactory/shared line 83 Annotation Problem (Java 6 processor) The type java.util.Mapjava.lang.String,java.lang.Integer cannot be used here BaseFooProxy.java /gwt-user/core/test/com/google/web/bindery/requestfactory/shared line 143 Annotation Problem (Java 6 processor) The method addTypeToken(String, String) is undefined for the type TypeTokenResolverBuilderImpl TypeTokenResolverBuilderImpl.java /gwt-user/.apt_generated/com/google/web/bindery/requestfactory/vm/impl line 4 Java Problem com.google.web.bindery.requestfactory.vm.impl.TypeTokenResolver cannot be resolved to a type TypeTokenResolverBuilderImpl.java /gwt-user/.apt_generated/com/google/web/bindery/requestfactory/vm/impl line 2 Java Problem The type java.util.Mapcom.google.web.bindery.requestfactory.shared.MapKeyProxy,com.google.web.bindery.requestfactory.shared.MapValueProxy cannot be used here BaseFooProxy.java /gwt-user/core/test/com/google/web/bindery/requestfactory/shared line 85 Annotation Problem (Java 6 processor) The type java.util.Mapjava.lang.Integer,com.google.web.bindery.requestfactory.shared.SimpleBarProxy cannot be used here BaseFooProxy.java /gwt-user/core/test/com/google/web/bindery/requestfactory/shared line 147 Annotation Problem (Java 6 processor) The type java.util.Mapcom.google.web.bindery.requestfactory.shared.SimpleBarProxy,java.lang.Integer cannot be used here BaseFooProxy.java /gwt-user/core/test/com/google/web/bindery/requestfactory/shared line 145 Annotation Problem (Java 6 processor) The method addTypeToken(String, String) is undefined for the type TypeTokenResolverBuilderImpl TypeTokenResolverBuilderImpl.java /gwt-user/.apt_generated/com/google/web/bindery/requestfactory/vm/impl line 6 Java Problem CSS file com/google/gwt/uibinder/test/client/Menu.css is missing WidgetBasedUi.ui.xml /gwt-user/core/test/com/google/gwt/uibinder/test/client line 110 Google Web Toolkit UiBinder Problem The method addTypeToken(String, String) is undefined for the type TypeTokenResolverBuilderImpl TypeTokenResolverBuilderImpl.java /gwt-user/.apt_generated/com/google/web/bindery/requestfactory/vm/impl line 5 Java Problem The type java.util.Mapcom.google.web.bindery.requestfactory.shared.MapKeyProxy,com.google.web.bindery.requestfactory.shared.MapValueProxy cannot be used here BaseFooProxy.java /gwt-user/core/test/com/google/web/bindery/requestfactory/shared line 149 Annotation Problem (Java 6 processor) So the first set of errors is related to using java.util.Map in EntityProxies (which I thought is forbidden), but it may have changed in recent versions, or maybe this version in trunk. In that case I need to compile with GWT version that is in trunk right? The project compiles successfully with ant, do I have to use the freshly compiled GWT instead of my current 2.6.1 ? *com.google.web.bindery.requestfactory.vm.impl.TypeTokenResolver *is a generated interface? I can't find it anywhere. I also have a doubt with the task in eclipse/README.txt : Project-Properties-Java Compiler-AnnotationProcessor-Factory Path - Add Variable - Select GWT_TOOLS and click Extend - Select lib/requestfactory and the most recently dated requestfactory-apt--MM-DD.jar the only one with a date is requestfactory-apt-2011-08-18.jar (is it the last one???). There are two other versions without a date one seems old too 'apt-2.5.1' and the other doesn't specify its version Thanks for your help p.s: if the error font is too small here they are again without formatting - Description Resource Path Location Type - The type java.util.Mapjava.lang.String,java.lang.Integer cannot be used here BaseFooProxy.java /gwt-user/core/test/com/google/web/bindery/requestfactory/shared line 79 Annotation Problem (Java 6 processor) - The type java.util.Mapjava.lang.Integer,com.google.web.bindery.requestfactory.shared.SimpleBarProxy cannot be used here
[gwt-contrib] Re: Errors in eclipse on gwt-user after cloning git
I also have a doubt with the task in eclipse/README.txt : Project-Properties-Java Compiler-AnnotationProcessor-Factory Path - Add Variable - Select GWT_TOOLS and click Extend - Select lib/requestfactory and the most recently dated requestfactory-apt--MM-DD.jar the only one with a date is requestfactory-apt-2011-08-18.jar (is it the last one???). There are two other versions without a date one seems old too 'apt-2.5.1' and the other doesn't specify its version I Just checked the jars in *tools/lib/requestfactory* I looked inside the jar and the files are old: all of the jars contain files from 2011 (do I have to take a newly built file? where do I find it?) -- 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/785cf768-6bed-4a3f-b1d4-170d9805fef0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Errors in eclipse on gwt-user after cloning git
Perfect Jens :-), Thanks a lot for all these valuable answers!! I can get started now Le mardi 20 mai 2014 11:26:09 UTC+1, Zied Hamdi OneView a écrit : Hi Gwt friends :) I wanted to start contributing to GWT, so I followed the instructions until I arrived to the point of using my eclipse. There I have the following errors (and since I don't want to change code that I don't want to submit I'm kind of stuck in what to do now?). The errors are the following: Description Resource Path Location Type The type java.util.Mapjava.lang.String,java.lang.Integer cannot be used here BaseFooProxy.java /gwt-user/core/test/com/google/web/bindery/requestfactory/shared line 79 Annotation Problem (Java 6 processor) The type java.util.Mapjava.lang.Integer,com.google.web.bindery.requestfactory.shared.SimpleBarProxy cannot be used here BaseFooProxy.java /gwt-user/core/test/com/google/web/bindery/requestfactory/shared line 81 Annotation Problem (Java 6 processor) The type java.util.Mapcom.google.web.bindery.requestfactory.shared.SimpleBarProxy,java.lang.Integer cannot be used here BaseFooProxy.java /gwt-user/core/test/com/google/web/bindery/requestfactory/shared line 83 Annotation Problem (Java 6 processor) The type java.util.Mapjava.lang.String,java.lang.Integer cannot be used here BaseFooProxy.java /gwt-user/core/test/com/google/web/bindery/requestfactory/shared line 143 Annotation Problem (Java 6 processor) The method addTypeToken(String, String) is undefined for the type TypeTokenResolverBuilderImpl TypeTokenResolverBuilderImpl.java /gwt-user/.apt_generated/com/google/web/bindery/requestfactory/vm/impl line 4 Java Problem com.google.web.bindery.requestfactory.vm.impl.TypeTokenResolver cannot be resolved to a type TypeTokenResolverBuilderImpl.java /gwt-user/.apt_generated/com/google/web/bindery/requestfactory/vm/impl line 2 Java Problem The type java.util.Mapcom.google.web.bindery.requestfactory.shared.MapKeyProxy,com.google.web.bindery.requestfactory.shared.MapValueProxy cannot be used here BaseFooProxy.java /gwt-user/core/test/com/google/web/bindery/requestfactory/shared line 85 Annotation Problem (Java 6 processor) The type java.util.Mapjava.lang.Integer,com.google.web.bindery.requestfactory.shared.SimpleBarProxy cannot be used here BaseFooProxy.java /gwt-user/core/test/com/google/web/bindery/requestfactory/shared line 147 Annotation Problem (Java 6 processor) The type java.util.Mapcom.google.web.bindery.requestfactory.shared.SimpleBarProxy,java.lang.Integer cannot be used here BaseFooProxy.java /gwt-user/core/test/com/google/web/bindery/requestfactory/shared line 145 Annotation Problem (Java 6 processor) The method addTypeToken(String, String) is undefined for the type TypeTokenResolverBuilderImpl TypeTokenResolverBuilderImpl.java /gwt-user/.apt_generated/com/google/web/bindery/requestfactory/vm/impl line 6 Java Problem CSS file com/google/gwt/uibinder/test/client/Menu.css is missing WidgetBasedUi.ui.xml /gwt-user/core/test/com/google/gwt/uibinder/test/client line 110 Google Web Toolkit UiBinder Problem The method addTypeToken(String, String) is undefined for the type TypeTokenResolverBuilderImpl TypeTokenResolverBuilderImpl.java /gwt-user/.apt_generated/com/google/web/bindery/requestfactory/vm/impl line 5 Java Problem The type java.util.Mapcom.google.web.bindery.requestfactory.shared.MapKeyProxy,com.google.web.bindery.requestfactory.shared.MapValueProxy cannot be used here BaseFooProxy.java /gwt-user/core/test/com/google/web/bindery/requestfactory/shared line 149 Annotation Problem (Java 6 processor) So the first set of errors is related to using java.util.Map in EntityProxies (which I thought is forbidden), but it may have changed in recent versions, or maybe this version in trunk. In that case I need to compile with GWT version that is in trunk right? The project compiles successfully with ant, do I have to use the freshly compiled GWT instead of my current 2.6.1 ? *com.google.web.bindery.requestfactory.vm.impl.TypeTokenResolver *is a generated interface? I can't find it anywhere. I also have a doubt with the task in eclipse/README.txt : Project-Properties-Java Compiler-AnnotationProcessor-Factory Path - Add Variable - Select GWT_TOOLS and click Extend - Select lib/requestfactory and the most recently dated requestfactory-apt--MM-DD.jar the only one with a date is requestfactory-apt-2011-08-18.jar (is it the last one???). There are two other versions without a date one seems old too 'apt-2.5.1' and the other doesn't specify its version Thanks for your help p.s: if the error font is too small here they are again without formatting - Description Resource Path Location Type - The type java.util.Mapjava.lang.String,java.lang.Integer cannot be used
[gwt-contrib] caching EntityProxy instances on the client between sessions
Hi All,
I have an issue with caching a list of almost static EntityProxies on the
client side.
First I checked the possibility to mark the url as cachable but since
RequestFactory urls are generated by GWT, it seamed too complicated to do.
I then decided to cache the EntityProxies in cookies. Saving to JSON was
ok, relaoding was a little tricky since I didn't get the point of all
methods declared in EntityProxyCategory (see the code below).
Finally things almost work but when I do a request, I receive a *SEVERE:
Server Error 413* (which is thrown by the servlet before processing the
request)
here's my code
@Category(LocalEntityProxyCategory.class)
protected interface CateoriesForCookieHolderFactory extends AutoBeanFactory
{
AutoBeanCategoriesForCookieHolder categoriesForCookieHolder();
AutoBeanCategoryProxy category();
AutoBeanContextDynamicFieldProxy contextDynamicFieldProxy();
}
public static class LocalEntityProxyCategory {
/**
* EntityProxies are equal if they are from the same RequestContext and
* their stableIds are equal.
*/
public static boolean equals(AutoBean? extends EntityProxy bean, Object
o) {
if (!(o instanceof EntityProxy)) {
return false;
}
AutoBeanEntityProxy other = AutoBeanUtils.getAutoBean((EntityProxy) o);
if (other == null) {
// Unexpected, could be an user-provided implementation?
return false;
}
// Object comparison intentional. True if both null or both the same
return stableId(bean).equals(stableId(other))
nonDiffingRequestContext(bean) == nonDiffingRequestContext(other);
}
/**
* Hashcode is always that of the stableId, since it's stable across time.
*/
public static int hashCode(AutoBean? extends EntityProxy bean) {
return stableId(bean).hashCode();
}
/**
* Effectively overrides {@link BaseProxyCategory#stableId(AutoBean)} to
* return a narrower bound.
*/
public static T extends EntityProxy EntityProxyIdT stableId(
final AutoBean? extends T bean) {
return new SimpleProxyIdT(bean);
}
private static AbstractRequestContext nonDiffingRequestContext(
AutoBean? bean) {
AbstractRequestContext context = requestContext(bean);
return context;
}
}
public class SimpleProxyIdT extends EntityProxy implements
EntityProxyIdT {
long id;
ClassT clazz;
@SuppressWarnings(unchecked)
public SimpleProxyId(AutoBean? extends T bean) {
BasicProxy proxy = (BasicProxy) bean.as();
id = proxy.getId();
clazz = (ClassT) proxy.getClass();
}
@Override
public ClassT getProxyClass() {
return clazz;
}
@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + ((clazz == null) ? 0 : clazz.hashCode());
result = prime * result + (int) (id ^ (id 32));
return result;
}
@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
SimpleProxyId other = (SimpleProxyId) obj;
if (clazz == null) {
if (other.clazz != null)
return false;
} else if (!clazz.equals(other.clazz))
return false;
if (id != other.id)
return false;
return true;
}
}
I think it is too complicated to do such caching (for what it is, maybe, it
could be a good idea to include a mechanism either for url resource caching
or for EntityProxy json read and write)
Best Regards,
Zied Hamdi
http://1vu.fr
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups
Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
