Re: [gwt-contrib] RR: Promoting RequestFactory to a higher package
We were only concerned about public api. Do you see anything we're missing there? On Apr 1, 2011 3:09 PM, Thomas Broyer t.bro...@gmail.com wrote: Note that AutoBeanUtils uses WeakMapping which lives in com.google.gwt.core.client (yes, this is a client class used in shared, and thus server code; WeakMapping is also directly referenced through server code, namely in ProxyAutoBean) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RR: Promoting RequestFactory to a higher package
Note that AutoBeanUtils uses WeakMapping which lives in com.google.gwt.core.client (yes, this is a client class used in shared, and thus server code; WeakMapping is also directly referenced through server code, namely in ProxyAutoBean) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RR: Promoting RequestFactory to a higher package
Yes, it's true, we spaced that EventBus is part of GWT's public API. We're now thinking that the new packages will be: com.google.bindery.event com.google.bindery.autobean com.google.bindery.requestfactory Patches should start appearing this week. Note that this is strictly a refactoring of code that is already JRE compatible. The i18n subthread is interesting, but out of scope for this effort. On Fri, Mar 25, 2011 at 2:53 PM, Stephen Haberman stephen.haber...@gmail.com wrote: Reactions? Having to change import statements sounds perfectly fine to me. Other misc comments from the peanut gallery, though likely nothing you guys haven't likely already figured out. Just curious. Should c.g.requestfactory have zero GWT dependencies? I.e. this non-GWT/pure JRE jar you spoke of would be everything in that package (without any build tricks to filter out GWT stuff)? Perhaps then GWT-specific RF code like any of the client/rebind code (and even GWT-coupled server code) should stay in c.g.g.requestfactory? Also, the new c.g.rf.shared.RequestFactory imports c.g.gwt's EventBus--no idea if that's a big deal or not, but seems odd if c.g.requestfactory is supposed to be reusable/non-GWT standalone (which, may very likely be a constraint I'm making up--it just seems elegant if non-GWT reuse is what you're after). - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RR: Promoting RequestFactory to a higher package
Note that this is strictly a refactoring of code that is already JRE compatible. Cool--for context then, are the non-GWT use cases: A) Java clients that aren't JavaScript (Swing/etc.) B) Javascript clients that aren't Java (pure JS) C) Something else? I originally assumed the reuse context was B, but if the client packages are getting moved, that makes me guess A. - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] RR: Promoting RequestFactory to a higher package
RequestFactory is proving itself useful in non-GWT contexts, so we would like to give it more independence. Our plan with the GWT 2.3 release is to copy com.google.gwt.requestfactory to com.google.requestfactory, and deprecate everything in the old location. We will also provide a jar that includes the pure JRE version of request factory with no other GWT dependencies. (This change will probably not make the first 2.3 milestone release.) With 2.4, we'll delete the code in the old location. This is faster than usual promise of keeping deprecated code in place for two releases, but we really don't want to leave so much redundant code around any longer than we have to. The API will not change; client code should be able to migrate by simply by changing import statements. Reactions? rjrjr -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RR: Promoting RequestFactory to a higher package
My reaction is that EventBus/SimpleEventBus and friends should be part of this On Fri, Mar 25, 2011 at 5:19 PM, Ray Ryan rj...@google.com wrote: RequestFactory is proving itself useful in non-GWT contexts, so we would like to give it more independence. Our plan with the GWT 2.3 release is to copy com.google.gwt.requestfactory to com.google.requestfactory, and deprecate everything in the old location. We will also provide a jar that includes the pure JRE version of request factory with no other GWT dependencies. (This change will probably not make the first 2.3 milestone release.) With 2.4, we'll delete the code in the old location. This is faster than usual promise of keeping deprecated code in place for two releases, but we really don't want to leave so much redundant code around any longer than we have to. The API will not change; client code should be able to migrate by simply by changing import statements. Reactions? rjrjr -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RR: Promoting RequestFactory to a higher package
Reactions? Having to change import statements sounds perfectly fine to me. Other misc comments from the peanut gallery, though likely nothing you guys haven't likely already figured out. Just curious. Should c.g.requestfactory have zero GWT dependencies? I.e. this non-GWT/pure JRE jar you spoke of would be everything in that package (without any build tricks to filter out GWT stuff)? Perhaps then GWT-specific RF code like any of the client/rebind code (and even GWT-coupled server code) should stay in c.g.g.requestfactory? Also, the new c.g.rf.shared.RequestFactory imports c.g.gwt's EventBus--no idea if that's a big deal or not, but seems odd if c.g.requestfactory is supposed to be reusable/non-GWT standalone (which, may very likely be a constraint I'm making up--it just seems elegant if non-GWT reuse is what you're after). - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
