[gwt-contrib] Re: Removed use of a global table (typeIdArray) for testing castability between types. This informa... (issue750801)
I have a working version now that removes the use of the typeId, that's passing our tests. I will clean it up and submit it as a separate patch tomorrow(unless you think it's worth adding to this one?) Jason http://gwt-code-reviews.appspot.com/750801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Enables setter methods to be directly called on Record/proxy objects, instead of going through a... (issue752802)
http://gwt-code-reviews.appspot.com/752802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Enables setter methods to be directly called on Record/proxy objects, instead of going through a... (issue752802)
http://gwt-code-reviews.appspot.com/752802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r8515 committed - PUBLIC: Fix compile errors in user/build.xml compile.tests target....
Revision: 8515 Author: gwt.mirror...@gmail.com Date: Tue Aug 10 20:34:17 2010 Log: PUBLIC: Fix compile errors in user/build.xml compile.tests target. Review at http://gwt-code-reviews.appspot.com/749801 Review by: rj...@google.com http://code.google.com/p/google-web-toolkit/source/detail?r=8515 Modified: /trunk/user/build.xml === --- /trunk/user/build.xml Thu Aug 5 13:48:12 2010 +++ /trunk/user/build.xml Tue Aug 10 20:34:17 2010 @@ -109,6 +109,7 @@ location="${gwt.tools.lib}/selenium/selenium-java-client-driver.jar" /> location="${gwt.tools}/redist/json/r2_20080312/json-1.5.jar" /> + location="${gwt.tools.lib}/javax/validation/validation-api-1.0.0.GA.jar" /> -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Enables setter methods to be directly called on Record/proxy objects, instead of going through a... (issue752802)
http://gwt-code-reviews.appspot.com/752802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Annotate the SpeedTracer log data with some extra info. (issue753801)
http://gwt-code-reviews.appspot.com/753801/diff/1/3 File dev/core/src/com/google/gwt/dev/javac/CompilationState.java (right): http://gwt-code-reviews.appspot.com/753801/diff/1/3#newcode93 dev/core/src/com/google/gwt/dev/javac/CompilationState.java:93: generatedUnitsAddEvent.addData("# new generated units", "" + generatedUnits.size()); Is this a valid JSON property name? I've nver used a # or spaces in one. http://gwt-code-reviews.appspot.com/753801/diff/1/4 File dev/core/src/com/google/gwt/dev/javac/JdtCompiler.java (right): http://gwt-code-reviews.appspot.com/753801/diff/1/4#newcode506 dev/core/src/com/google/gwt/dev/javac/JdtCompiler.java:506: jdtCompilerEvent.end("# icus", "" + icus.size()); same comment http://gwt-code-reviews.appspot.com/753801/diff/1/9 File dev/core/src/com/google/gwt/dev/shell/ShellModuleSpaceHost.java (right): http://gwt-code-reviews.appspot.com/753801/diff/1/9#newcode94 dev/core/src/com/google/gwt/dev/shell/ShellModuleSpaceHost.java:94: whitespace http://gwt-code-reviews.appspot.com/753801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Enables setter methods to be directly called on Record/proxy objects, instead of going through a... (issue752802)
Reviewers: cromwellian, Ray Ryan, robertvawter, Description: Enables setter methods to be directly called on Record/proxy objects, instead of going through a DeltaValueStore. Also removes the now unnecessary DeltaValueStore from the public api. Patch by: amitmanjhi Review by: rjrjr, cromwellian, robertvawter Please review this at http://gwt-code-reviews.appspot.com/752802/show Affected files: M bikeshed/src/com/google/gwt/sample/expenses/gwt/client/ExpenseDetails.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/client/MobileExpenseEntry.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/client/MobileReportEntry.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/request/EmployeeRecord.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/request/ExpenseRecord.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/request/ExpenseRequest.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/request/ReportRecord.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/ui/employee/EmployeeDetailsActivity.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/ui/employee/EmployeeEditView.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/ui/report/ReportDetailsActivity.java M user/src/com/google/gwt/app/place/AbstractRecordEditActivity.java M user/src/com/google/gwt/app/place/RecordEditView.java M user/src/com/google/gwt/app/rebind/EditorSupportGenerator.java M user/src/com/google/gwt/requestfactory/client/impl/AbstractRequest.java M user/src/com/google/gwt/requestfactory/client/impl/DeltaValueStoreJsonImpl.java M user/src/com/google/gwt/requestfactory/client/impl/RequestFactoryJsonImpl.java M user/src/com/google/gwt/requestfactory/rebind/RequestFactoryGenerator.java D user/src/com/google/gwt/requestfactory/shared/DeltaValueStore.java M user/src/com/google/gwt/requestfactory/shared/RequestObject.java M user/src/com/google/gwt/valuestore/shared/impl/RecordImpl.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add Mnemonics/Shortcuts for frequently used buttons on the Dev Shell (Swing UI) (issue708801)
What's about a commit to the main trunk? The patch still hasn't been applied although it's been accepted: http://code.google.com/p/google-web-toolkit/issues/detail?id=5150 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Annotate the SpeedTracer log data with some extra info. (issue753801)
Reviewers: zundel, Description: Annotate the SpeedTracer log data with some extra info. Also, remove some unused event types and fiddle with the colors to make DevMode traces a bit more readable. Please review this at http://gwt-code-reviews.appspot.com/753801/show Affected files: M dev/core/src/com/google/gwt/dev/DevModeBase.java M dev/core/src/com/google/gwt/dev/javac/CompilationState.java M dev/core/src/com/google/gwt/dev/javac/JdtCompiler.java M dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java M dev/core/src/com/google/gwt/dev/shell/ModuleSpace.java M dev/core/src/com/google/gwt/dev/shell/ModuleSpaceOOPHM.java M dev/core/src/com/google/gwt/dev/shell/OophmSessionHandler.java M dev/core/src/com/google/gwt/dev/shell/ShellModuleSpaceHost.java M dev/core/src/com/google/gwt/dev/shell/StandardRebindOracle.java M dev/core/src/com/google/gwt/dev/shell/rewrite/HostedModeClassRewriter.java M dev/core/src/com/google/gwt/dev/util/log/speedtracer/CompilerEventType.java M dev/core/src/com/google/gwt/dev/util/log/speedtracer/DevModeEventType.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [google-gin] Re: [gwt-contrib] RR: What if UiBinder could take a factory?
On Tue, Aug 10, 2010 at 11:01 AM, Peter Schmitt wrote: > I think the scheme I sketched gets around this issue. Gin isn't aware of >> any of the generated code. Rather, the generated code is aware of the public >> Ginjector interface. When Gin is asked to inject a MyUiBinder, it's just >> going to write GWT.create(MyUiBinder), and then call that instance's >> setFactory() method with itself. So this code: >> >> @Inject >> public MyWidget(MyUiBinder binder) extends Composite { >> >> public interface MyUiBinder extends UiBinderWithFactory> MyWidget, >> MyGinjector> { >> @Inject setFactory(MyGinjector factory); >> } >> } >> >> >> makes Gin generate the moral equivalent of >> >> new >> MyWidget((MyUiBinder.class) GWT.create(MyUiBinder.class)).setFactory(this); >> >> > Yes, this should work. It requires some boilerplate on the ginjector (which > often contains just a single method) but it has the advantage of not > requiring any additional infrastructure. > > >> Also, while I was assuming that for the most part the binder would be >> working off of the Ye One True Ginjector, there is no actual requirement >> that you do so, nor that your Factory be Ginjector at al. E.g.: >> >> @Inject >> public MyWidget(MyUiBinder binder) extends Composite { >> >> public static class Factory { >> @Inject @MagicScope EventBus eventBus; >> >> FooWidget makeAFoo() { >> return new Foo(eventBus); >> } >> } >> >> public interface MyUiBinder extends UiBinderWithFactory> MyWidget, >> MyGinjector> { >> @Inject setFactory(Factory factory); >> } >> } >> >> > No problem - this factory is essentially a provider, although in the usual > case it will have more than one creator method? You can also abuse assisted > inject here to have Gin generate the implementation for the factory > interface (assisted inject won't complain if you don't pass any local > variables :). > Slick. I'll have to read up on that. > > >> And if it's possible for one Ginjector to create another (haven't been >> paying attention, sorry), that boilerplate could perhaps be even less? >> >> @Inject >> public MyWidget(MyUiBinder binder) extends Composite { >> >> @MagicScope >> public interface Factory extends Ginjector { >> EventBus eventBus; >> } >> >> public interface MyUiBinder extends UiBinderWithFactory> MyWidget, >> MyGinjector> { >> @Inject setFactory(Factory factory); >> } >> } >> >> > While this works in theory, you probably want a new ginjector that actually > inherits the injection framework of the original ginjector - otherwise it > won't have any of the bindings. Probably easier to use assisted inject as > outlined above. > > >> I think what we want is a class generated by UiBinder that has @Inject >>> annotated constructor/fields/methods for its required children and is then >>> used as input by the Gin generator to wire the injection up. But to >>> accomplish that, we'll need to fix the issue mentioned above. >>> >>> How does this sound? >>> >> >> Like it would need a lot more thought and a lot more work :-). (Although >> it's a nicely DI-framework-agnostic notion, now that the annotations live in >> javax.). We really wouldn't just want limit you to putting @Inject on >> everything, you'd want the full gin experience — e.g. to be allowed to put >> other annotations on specific fields, right? All of a sudden we have to >> provide an annotation syntax for ui.xml. >> >> Don't get me wrong, I would rather fix GWT.create() so that Ginjector >> actually could efficiently provide a getInstance(...) method, and to allow >> gin to see generated code. But those two conversations never seem to >> terminate, and I don't have the chops to just do them myself. So my question >> is: if we accept the current limitations, would this change be a worthwhile >> incremental step? >> > > Yes, we should do the simple solution first. I'd really like to fix the > generator interaction challenge though, it would solve tons of other > problems as well. > I'll try to get this done, as I think it may solve a number of problems for me, but no ETA. Re: the correct solution, I don't think any of us can raise our hand. But I bet we could get you pointed in the right direction if you want to roll up your sleeves. > > > >> >>> Peter >>> >>> >>> >>> > public interface UiBinderWithFactory extends UiBinder { > /** >* Sets a factory to use when instantiating objects that are not >* provided via @UiFactory methods or @UiField(provided = true) fields. >* >* When an instance is needed, a zero args method with an appropriate > return type >* will be sought on the factory to provide it. If none is found > GWT.create() >* will be used instead. >* >* It is a compile time error for the factory to provide ambiguous > methods. >*/ > setFactory(F factory); > } > > You might wind up with
[gwt-contrib] For synthetic this refs, use params rather than fields while in constructors (issue752801)
Reviewers: tobyr, Please review this at http://gwt-code-reviews.appspot.com/752801/show Affected files: M dev/core/src/com/google/gwt/dev/jjs/ast/JField.java M dev/core/src/com/google/gwt/dev/jjs/impl/BuildTypeMap.java M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on CssResource in google-web-toolkit
Comment by ehboto: It would be useful to allow usage of the @media rule in the resource's css file: http://www.w3.org/TR/CSS2/media.html#at-media-rule That way making widgets that work both on the screen and when printed wouldn't require any wacky workarounds. (btw there's already an issue for this http://code.google.com/p/google-web-toolkit/issues/detail?id=4911) For more information: http://code.google.com/p/google-web-toolkit/wiki/CssResource -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: When dev mode fails to load a module, update the $wnd.title with a summary of the (issue750802)
LGTM -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Create a red dev mode glass panel when hosted mode fails to load your module, similar to the gra... (issue730802)
Did I already mention how awesome it is that you fixed this? awesome! /kelly On Tue, Aug 10, 2010 at 5:05 PM, wrote: > Committed in r8509 > > http://code.google.com/p/google-web-toolkit/source/detail?r=8509 > > > > http://gwt-code-reviews.appspot.com/730802/show > -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] When dev mode fails to load a module, update the $wnd.title with a summary of the (issue750802)
Reviewers: scottb, Description: When dev mode fails to load a module, update the $wnd.title with a summary of the error, so that the error can be seen even when the browser is minimized in task bar. This can be useful when developing by keeping all windows full-screen, i.e. it can save the developer from having to CMD-TAB/ALT-TAB between editor and browser to see the error. This work continues where r8509 left off. Fixes Issues: 1617 Review by: sco...@google.com Please review this at http://gwt-code-reviews.appspot.com/750802/show Affected files: M dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html Index: dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html === --- dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html (revision 8509) +++ dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html (working copy) @@ -202,6 +202,8 @@ // Nasty CSS; onresize would be better but the outer window won't let us add a listener IE. glassStyle.setExpression("height", "document.documentElement.clientHeight"); } + + $doc.title = summary + " [" + $doc.title + "]"; } function findPluginObject() { -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Allow RPC stats system extensions (issue751801)
Reviewers: Dan Rice, scottb, Lex, Description: This patch allows for the extension of the RPC stats system by "moving" the stats methods into an object, making them non-static. This would allow application developers to extend the ProxyCreator to use a different implementation of the stats methods. Please review this at http://gwt-code-reviews.appspot.com/751801/show Affected files: user/src/com/google/gwt/rpc/client/impl/RpcCallbackAdapter.java user/src/com/google/gwt/rpc/client/impl/RpcServiceProxy.java user/src/com/google/gwt/user/client/rpc/impl/RemoteServiceProxy.java user/src/com/google/gwt/user/client/rpc/impl/RequestCallbackAdapter.java user/src/com/google/gwt/user/client/rpc/impl/RpcStatsContext.java user/src/com/google/gwt/user/rebind/rpc/ProxyCreator.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Create a red dev mode glass panel when hosted mode fails to load your module, similar to the gra... (issue730802)
Committed in r8509 http://code.google.com/p/google-web-toolkit/source/detail?r=8509 http://gwt-code-reviews.appspot.com/730802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Why is JClassType#getAnnotations() not public?
On Sun, Aug 8, 2010 at 3:57 PM, PhilBeaudoin wrote: > In one of my generator I would need to scan the list of all > annotations in order to find one that is marked with another > annotation. Unfortunately, there doesn't seem to be any public > mechanism in JClassType to access the list of all annotations. Looking > at the class I see: > getAnnotations() > and > getDeclaredAnnotations() > that would do exactly what I need, but they have default visibility > and are indicated "for testing purposes only". Is there any reason why > these method couldn't be made public? > If you are looking for a particular annotation, why not use jct.getAnnotation(Class) or jct.findAnnotationInTypeHierarchy(Class) if it should be inherited? -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the size of a widget in the (issue719802)
http://gwt-code-reviews.appspot.com/719802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Faster edit-distance computation in JsFunctionClusterer (issue669801)
http://gwt-code-reviews.appspot.com/669801/diff/33001/34006 File dev/core/src/com/google/gwt/dev/jjs/impl/JsFunctionClusterer.java (right): http://gwt-code-reviews.appspot.com/669801/diff/33001/34006#newcode43 dev/core/src/com/google/gwt/dev/jjs/impl/JsFunctionClusterer.java:43: Pattern.compile("function |[_a-zA-Z$][.$_a-zA-Z0-9]*=function"); This regex will incorrect match vtable declarations of the form: _.name = function() { ... } These prototype declarations cannot be re-ordered, so don't let it match a single '_' symbol. On 2010/08/05 23:02:48, Alexandre Vassalotti wrote: On 2010/08/05 19:27:01, zundel wrote: > Wait a minute, what happened to the caret? This means any line with the string > "function " in it will match. Is that what we want? This is not an issue since the lookingAt() method, which matches only at the beginning of a string, is used in isFunctionDeclaration(). http://gwt-code-reviews.appspot.com/669801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Removed use of a global table (typeIdArray) for testing castability between types. This informa... (issue750801)
Scott, I'm working on getting rid of it now (I'll create a different bug issue). My quick and dirty attempt to get rid of it had a few issues, so I decided to release the main typeIdArray change first. Yes, I agree, it should be able to be gotten rid of, since it's main purpose was indeed to be nothing more than an index into the typeIdArray table. There are some special cases where it is still used, such as to decide if something is a String/JSO (i.e. there are checks in the code literally for "typeId == 2")So, need to factor out those special cases. Also, need to understand whether it will affect deRPC stuff. Jason On Tue, Aug 10, 2010 at 2:38 PM, wrote: > Q: Can Object.typeId be gotten rid of? If not, what else is it being > used for? > > http://gwt-code-reviews.appspot.com/750801/show > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Removed trim in ValueBoxBase, forcing parsers to handle trim()ing. (issue738801)
http://gwt-code-reviews.appspot.com/738801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Problem in Large scale application development and MVP
I recently tried to follow the Large scale application development and MVP tutorial. The tutorial was great but I am having a hard time with a few things. If you try and add a contact to the list, the contact is created. If you try and add another contact, you are taken to the edit screen of the last contact you created. No more contacts can be added once you add your first contact. What needs to be changed so you can add more than one contact. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the size of a widget in the (issue719802)
On Mon, Aug 2, 2010 at 2:14 PM, wrote: > > http://gwt-code-reviews.appspot.com/719802/diff/1/2 > File user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java > (right): > > http://gwt-code-reviews.appspot.com/719802/diff/1/2#newcode315 > user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java:315: public > > void setWidgetSize(Widget widget, int size) { > This needs to be a double (all units except PX can be non-integral). True, just eclipse auto create method getting in the way, done. > > > http://gwt-code-reviews.appspot.com/719802/show > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Removed trim in ValueBoxBase, forcing parsers to handle trim()ing. (issue738801)
http://gwt-code-reviews.appspot.com/738801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] GWT-RPC generic object serialization...
It seems that the issue of generic Object serialization comes up a lot in the arena of GWT-RPC, but good solutions seem to be far more elusive than the postings of the problem. The most relevant proposed solution that I found came from Scott Blum ( http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/25d151960b48b5c4#) nearly 2 years ago. Before finding this solution, I was faced with the problem and as the saying goes, "Necessity is the mother of invention", I came up with my own solution that is very different than Scott's. I posted a write-up on my solution on the StackOverflow forum ( http://stackoverflow.com/questions/2210226/how-can-i-keep-gwt-from-trying-to-include-every-serializable-class-when-i-use-arr/3385509#3385509), but unfortunately, I haven't received any feedback on it. I also contact Scott Blum who suggested that I post my message here (as he hasn't been involved with GWT-RPC for some time). I am really looking for some confirmation or at least comments or feedback of some sort on my approach, so I am hoping that by posting here I can get that; the school of GWT thought far exceeds my experience with technology. I won't repeat the entire stackoverflow posting here as the interested reader can obviously reference it if necessary, but I will include my version of a RPC-able generic object which is the core of the solution. If would seem that if GWT could provide a standard object of this type/functionality, then the masses would...errr might...stop reinventing the wheel; I am sure that the developers of GWT can do this better than me; however, there may be a significant downside/short-coming of this approach that I am overlooking (but at least for now, it is working great in practice for me). All thoughts and comments are appreciated! -Jeff public class RpcObject implements IsSerializable { protected HashMap rpcObjectWrapper = new HashMap(); /* * NOTE: The following fields are here to * trick/fool/work-around/whatever-you-want-to-call-it GWT-RPC's * serialization policy. Having these types present, even though their * corresponding fields are never used directly, enables GWT-RPC to * serialize/deserialize these primitive types if they are encountered in * the rpcWrapperObject! Of course GWT-RPC already knows how to serialize * all these primitive types, but since, for example, String doesn't * implement GWT's IsSerializable interface, GWT has no expectation that it * should ever be allowed in the rpcWrapperObject instance (and thus String, * as well as all the other Java primitives plus Arrays of such types as * well as List, Set, and Map, won't be part of the serialization policy of * the RpcObject type). This is unfortunate because thanks to java type * erasure, we can easily stuff Strings, Integers, etc into the wrapper * without any issues; however, GWT-RPC will cowardly refuse to serialize * them. Thankfully, it appears that the serialization policy is for the * RpcObject type as a whole rather than for the rpcObjectWrapper field * specifically. So, if we just add some dummy fields with these "primitive" * types they will get added to the serialization policy (they are * effectively white-listed) of the type as a whole, and alas, GWT-RPC stops * cowardly refusing to serialize them. */ protected Byte _byte; protected Short _short; protected Integer _integer; protected Long _long; protected Float _float; protected Double _double; protected Date _date; protected Boolean _boolean; protected Byte[] _bytes; protected Short[] _shorts; protected Integer[] _integers; protected Long[] _longs; protected Float[] _floats; protected Double[] _doubles; protected Date[] _dates; protected Boolean[] _booleans; protected List _list; protected Set _set; protected Map _map; public RpcObject() { super(); } public RpcObject(final Object value) { super(); this.setValue(value); } @SuppressWarnings("unchecked") public X getValue() { HashMap h = (HashMap) rpcObjectWrapper; X value = (X) h.get("value"); return value; } @SuppressWarnings("unchecked") public void setValue(Object value) { HashMap h = (HashMap) rpcObjectWrapper; h.put("value", value); } } -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Add the ability to change the size of a widget in the (issue719802)
Reviewers: jgw, Description: Add the ability to change the size of a widget in the DockLayoutPanel after it has already been added. Please review this at http://gwt-code-reviews.appspot.com/719802/show Affected files: M user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java Index: user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java === --- user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java (revision 8450) +++ user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java (working copy) @@ -304,6 +304,26 @@ return removed; } + + /** + * Updates the size of the widget passed in as long as it is not the center + * widget and updates the layout of the dock. + * + * @param widget the widget that needs to update its size + * @param size the size to update the widget to + */ + public void setWidgetSize(Widget widget, int size) { +assertIsChild(widget); +LayoutData data = (LayoutData) widget.getLayoutData(); + +assert data.direction != Direction.CENTER : +"The size of the center widget can not be updated."; + +data.size = size; + +// Update the layout. +animate(0); + } protected Widget getCenter() { return center; -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Generating Image with Generator
Hello, I'm trying to generate a bunch of ClientBundles with the associated images in the same directory. I can't figure out how to write the image files to the same directory as the java files generated with GeneratorContext.tryCreate(...). I also tried using GeneratorContext.tryCreateResource however the committed file ended up in my war directory. Is there a way I can get a reference to the generated directory? Cheers, Anthony -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Why is JClassType#getAnnotations() not public?
Hi, In one of my generator I would need to scan the list of all annotations in order to find one that is marked with another annotation. Unfortunately, there doesn't seem to be any public mechanism in JClassType to access the list of all annotations. Looking at the class I see: getAnnotations() and getDeclaredAnnotations() that would do exactly what I need, but they have default visibility and are indicated "for testing purposes only". Is there any reason why these method couldn't be made public? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Removed use of a global table (typeIdArray) for testing castability between types. This informa... (issue750801)
Reviewers: scottb, robertvawter, cromwellian, Description: Removed use of a global table (typeIdArray) for testing castability between types. This information is now stored per class prototype as a castableMap. Please review this at http://gwt-code-reviews.appspot.com/750801/show Affected files: M dev/core/src/com/google/gwt/core/ext/linker/SymbolData.java M dev/core/src/com/google/gwt/core/ext/linker/impl/StandardSymbolData.java M dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java M dev/core/src/com/google/gwt/dev/jjs/impl/ArrayNormalizer.java M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java M dev/core/super/com/google/gwt/dev/jjs/intrinsic/com/google/gwt/lang/Array.java M dev/core/super/com/google/gwt/dev/jjs/intrinsic/com/google/gwt/lang/Cast.java M dev/core/super/com/google/gwt/dev/jjs/intrinsic/com/google/gwt/lang/Util.java M tools/api-checker/config/gwt20_21userApi.conf M user/src/com/google/gwt/rpc/linker/ClientOracleLinker.java M user/src/com/google/gwt/rpc/server/ClientOracle.java M user/src/com/google/gwt/rpc/server/DelegatingClientOracle.java M user/src/com/google/gwt/rpc/server/HostedModeClientOracle.java M user/src/com/google/gwt/rpc/server/WebModeClientOracle.java M user/src/com/google/gwt/rpc/server/WebModePayloadSink.java M user/super/com/google/gwt/emul/java/lang/Object.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Removed trim in ValueBoxBase, forcing parsers to handle trim()ing. (issue738801)
Reviewers: knorton, Description: Removed trim in ValueBoxBase, forcing parsers to handle trim()ing. Please review this at http://gwt-code-reviews.appspot.com/738801/show Affected files: M user/src/com/google/gwt/user/client/ui/ValueBoxBase.java Index: user/src/com/google/gwt/user/client/ui/ValueBoxBase.java === --- user/src/com/google/gwt/user/client/ui/ValueBoxBase.java(revision 8466) +++ user/src/com/google/gwt/user/client/ui/ValueBoxBase.java(working copy) @@ -196,7 +196,7 @@ * @throws ParseException if the value cannot be parsed */ public T getValueOrThrow() throws ParseException { -String text = getText().trim(); +String text = getText(); if ("".equals(text)) { return null; -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Thoughts on GWT-RPC generic object serialization
It seems that the issue of having a mechanism for generic GWT-RPC object serialization comes up frequently. While the motivation by the developer for being able to do this in their code varies, the end result is generally the same: a reference explicitly or implicitly is made for GWT to serialize java.io.Serializable which then triggers the GWT compiler to "go crazy" and generate code for every serializable object on the class path. In the best case, this merely results in bloated code; in the worst case, it results in a project that fails on the server with ClassNotFound exceptions during GWT-RPC (I can provide the specifics if anyone is interested). In the situations that I have encountered, the developer typically wants to build a generic GWT-RPC service where all they know about the type of the argument(s) or return value is that GWT can serialize it...the type may be a type from the JRE that GWT emulates (String, Long, Date, etc) and can serialize or an object of their own creation which I will assume can be made to implement com.google.gwt.user.client.rpc.IsSerializable. The other common case is the desire to pass or return collections such as List or Map where, again, the developer only knows that Object will be of a type that GWT can serialize. There is a thread from 2008 (http://groups.google.com/group/Google-Web- Toolkit-Contributors/browse_thread/thread/25d151960b48b5c4#) that proposes one possible workaround. Before finding that solution, I invented one on my own and posted it in response to a forum post on the StackOverflow list (http://stackoverflow.com/questions/2210226/how- can-i-keep-gwt-from-trying-to-include-every-serializable-class-when-i- use-arr/3385509#3385509); unfortunately, my post hasn't received any feedback. I don't feel nearly as strongly about the specific implementation of a solution as I do that developers shouldn't have to invent workarounds like this on their own. To that end, I am posting my implementation (see below) for a class called RpcObject, and I would like feedback: is the implementation sound, or are there suggestions for improvement? should a class of this sort be provided by GWT? is there interest in having it be a project of GWT-contrib? In the event that I am native in my understanding of GWT-RPC and there is already a better way to accomplish this [or there is one on the roadmap], please let me know. -Jeff import java.util.Date; import java.util.HashMap; import java.util.List; import java.util.Map; import java.util.Set; import com.google.gwt.user.client.rpc.IsSerializable; public class RpcObject implements IsSerializable { protected HashMap rpcObjectWrapper = new HashMap(); /* * NOTE: The following fields are here to * trick/fool/work-around/whatever-you-want-to-call-it GWT-RPC's * serialization policy. Having these types present, even though their * corresponding fields are never used directly, enables GWT-RPC to * serialize/deserialize these primitive types if they are encountered in * the rpcWrapperObject! Of course GWT-RPC already knows how to serialize * all these primitive types, but since, for example, String doesn't * implement GWT's IsSerializable interface, GWT has no expectation that it * should ever be allowed in the rpcWrapperObject instance (and thus String, * as well as all the other Java primitives plus Arrays of such types as * well as List, Set, and Map, won't be part of the serialization policy of * the RpcObject type). This is unfortunate because thanks to java type * erasure, we can easily stuff Strings, Integers, etc into the wrapper * without any issues; however, GWT-RPC will cowardly refuse to serialize * them. Thankfully, it appears that the serialization policy is for the * RpcObject type as a whole rather than for the rpcObjectWrapper field * specifically. So, if we just add some dummy fields with these "primitive" * types they will get added to the serialization policy (they are * effectively white-listed) of the type as a whole, and alas, GWT- RPC stops * cowardly refusing to serialize them. */ protected Byte _byte; protected Short _short; protected Integer _integer; protected Long _long; protected Float _float; protected Double _double; protected Date _date; protected Boolean _boolean; protected Byte[] _bytes; protected Short[] _shorts; protected Integer[] _integers; protected Long[] _longs; protected Float[] _floats; protected Double[] _doubles; protected Date[] _dates; protected Boolean[] _booleans; protected List _list; protected Set _set; protected Map _map; public RpcObject() { super(); } public RpcObject(final Object va
[gwt-contrib] [google-web-toolkit] r8513 committed - Better error message on garbage in text....
Revision: 8513 Author: gwt.mirror...@gmail.com Date: Tue Aug 10 08:37:35 2010 Log: Better error message on garbage in text. Review at http://gwt-code-reviews.appspot.com/748801 Review by: cheng...@google.com http://code.google.com/p/google-web-toolkit/source/detail?r=8513 Modified: /trunk/user/src/com/google/gwt/uibinder/client/UiFactory.java /trunk/user/src/com/google/gwt/uibinder/rebind/XMLElement.java /trunk/user/src/com/google/gwt/user/client/ui/HTMLPanel.java === --- /trunk/user/src/com/google/gwt/uibinder/client/UiFactory.java Wed Oct 28 09:10:53 2009 +++ /trunk/user/src/com/google/gwt/uibinder/client/UiFactory.java Tue Aug 10 08:37:35 2010 @@ -23,7 +23,7 @@ /** * Marks a method that may be called as an alternative to a GWT.create call in a - * {...@link UiBinder} template. The parameter names of the constructor are treated + * {...@link UiBinder} template. The parameter names of the method are treated * as required xml element attribute values. * * It is an error to apply this annotation to more than one method of a given === --- /trunk/user/src/com/google/gwt/uibinder/rebind/XMLElement.java Fri Jul 23 14:20:15 2010 +++ /trunk/user/src/com/google/gwt/uibinder/rebind/XMLElement.java Tue Aug 10 08:37:35 2010 @@ -485,7 +485,9 @@ // Make sure there are no children left but empty husks for (XMLElement child : consumeChildElementsNoEmptyCheck()) { if (child.hasChildNodes() || child.getAttributeCount() > 0) { -logger.die(this, "Element has illegal child %s", child); +logger.die(this, "Illegal child %s in a text-only context. " + + "Perhaps you are trying to use unescaped HTML " + + "where text is required, as in a HasText widget?", child); } } === --- /trunk/user/src/com/google/gwt/user/client/ui/HTMLPanel.java Fri Mar 19 08:12:41 2010 +++ /trunk/user/src/com/google/gwt/user/client/ui/HTMLPanel.java Tue Aug 10 08:37:35 2010 @@ -107,7 +107,9 @@ } /** - * Adds a child widget to the panel, contained within an HTML element. + * Adds a child widget to the panel, contained within an HTML + * element. It is up to the caller to ensure that the given element + * is a child of this panel's root element. * * @param widget the widget to be added * @param elem the element within which it will be contained -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Removed use of a global table (typeIdArray) for testing castability between types. This informa... (issue750801)
Q: Can Object.typeId be gotten rid of? If not, what else is it being used for? http://gwt-code-reviews.appspot.com/750801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit
Comment by natewingone: @br...@google.com: It's not just mobile apps that want every byte to count. If you use GWT to enhance a largely static website, and the website must be fast to load for new users, you have to make sure javascript is as small as possible. For comparison the current collections are used all over the place in the widget/event libraries, and ArrayList alone uses around 8k. For more information: http://code.google.com/p/google-web-toolkit/wiki/LightweightCollections -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r8512 committed - Update the script to target M3 in response to Roo's commit 476ec5f35a3...
Revision: 8512 Author: gwt.mirror...@gmail.com Date: Tue Aug 10 08:07:22 2010 Log: Update the script to target M3 in response to Roo's commit 476ec5f35a3d8fc65b66834527ca1 Patch by: amitmanjhi Review by: rjrjr http://code.google.com/p/google-web-toolkit/source/detail?r=8512 Modified: /trunk/tools/scripts/maven_script.sh === --- /trunk/tools/scripts/maven_script.shThu Jul 8 08:12:05 2010 +++ /trunk/tools/scripts/maven_script.shTue Aug 10 08:07:22 2010 @@ -22,8 +22,8 @@ for i in dev user servlet do - mvn install:install-file -DgroupId=com.google.gwt -DartifactId=gwt-${i} -Dversion=2.1.0.M2 -Dpackaging=jar -Dfile=build/lib/gwt-${i}.jar -DgeneratePom=true + mvn install:install-file -DgroupId=com.google.gwt -DartifactId=gwt-${i} -Dversion=2.1.0.M3 -Dpackaging=jar -Dfile=build/lib/gwt-${i}.jar -DgeneratePom=true done touch /tmp/empty-fake-soyc-vis.jar -mvn install:install-file -DgroupId=com.google.gwt -DartifactId=gwt-soyc-vis -Dversion=2.1.0.M2 -Dpackaging=jar -DgeneratePom=true -Dfile=/tmp/empty-fake-soyc-vis.jar +mvn install:install-file -DgroupId=com.google.gwt -DartifactId=gwt-soyc-vis -Dversion=2.1.0.M3 -Dpackaging=jar -DgeneratePom=true -Dfile=/tmp/empty-fake-soyc-vis.jar echo "installed the gwt libs in the maven repo" -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Replacing ListView with HasData and HasRows (issue745801)
committed as r8511 http://gwt-code-reviews.appspot.com/745801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Replacing ListView with HasData and HasRows (issue723801)
committed as r8511 http://gwt-code-reviews.appspot.com/723801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [google-gin] Re: [gwt-contrib] RR: What if UiBinder could take a factory?
> > I think the scheme I sketched gets around this issue. Gin isn't aware of > any of the generated code. Rather, the generated code is aware of the public > Ginjector interface. When Gin is asked to inject a MyUiBinder, it's just > going to write GWT.create(MyUiBinder), and then call that instance's > setFactory() method with itself. So this code: > > @Inject > public MyWidget(MyUiBinder binder) extends Composite { > > public interface MyUiBinder extends UiBinderWithFactory MyGinjector> { > @Inject setFactory(MyGinjector factory); > } > } > > > makes Gin generate the moral equivalent of > > new > MyWidget((MyUiBinder.class) GWT.create(MyUiBinder.class)).setFactory(this); > > Yes, this should work. It requires some boilerplate on the ginjector (which often contains just a single method) but it has the advantage of not requiring any additional infrastructure. > Also, while I was assuming that for the most part the binder would be > working off of the Ye One True Ginjector, there is no actual requirement > that you do so, nor that your Factory be Ginjector at al. E.g.: > > @Inject > public MyWidget(MyUiBinder binder) extends Composite { > > public static class Factory { > @Inject @MagicScope EventBus eventBus; > > FooWidget makeAFoo() { > return new Foo(eventBus); > } > } > > public interface MyUiBinder extends UiBinderWithFactory MyGinjector> { > @Inject setFactory(Factory factory); > } > } > > No problem - this factory is essentially a provider, although in the usual case it will have more than one creator method? You can also abuse assisted inject here to have Gin generate the implementation for the factory interface (assisted inject won't complain if you don't pass any local variables :). > And if it's possible for one Ginjector to create another (haven't been > paying attention, sorry), that boilerplate could perhaps be even less? > > @Inject > public MyWidget(MyUiBinder binder) extends Composite { > > @MagicScope > public interface Factory extends Ginjector { > EventBus eventBus; > } > > public interface MyUiBinder extends UiBinderWithFactory MyGinjector> { > @Inject setFactory(Factory factory); > } > } > > While this works in theory, you probably want a new ginjector that actually inherits the injection framework of the original ginjector - otherwise it won't have any of the bindings. Probably easier to use assisted inject as outlined above. > I think what we want is a class generated by UiBinder that has @Inject >> annotated constructor/fields/methods for its required children and is then >> used as input by the Gin generator to wire the injection up. But to >> accomplish that, we'll need to fix the issue mentioned above. >> >> How does this sound? >> > > Like it would need a lot more thought and a lot more work :-). (Although > it's a nicely DI-framework-agnostic notion, now that the annotations live in > javax.). We really wouldn't just want limit you to putting @Inject on > everything, you'd want the full gin experience — e.g. to be allowed to put > other annotations on specific fields, right? All of a sudden we have to > provide an annotation syntax for ui.xml. > > Don't get me wrong, I would rather fix GWT.create() so that Ginjector > actually could efficiently provide a getInstance(...) method, and to allow > gin to see generated code. But those two conversations never seem to > terminate, and I don't have the chops to just do them myself. So my question > is: if we accept the current limitations, would this change be a worthwhile > incremental step? > Yes, we should do the simple solution first. I'd really like to fix the generator interaction challenge though, it would solve tons of other problems as well. > >> Peter >> >> >> >> >>> > public interface UiBinderWithFactory extends UiBinder { >>> > /** >>> >* Sets a factory to use when instantiating objects that are not >>> >* provided via @UiFactory methods or @UiField(provided = true) >>> fields. >>> >* >>> >* When an instance is needed, a zero args method with an appropriate >>> > return type >>> >* will be sought on the factory to provide it. If none is found >>> > GWT.create() >>> >* will be used instead. >>> >* >>> >* It is a compile time error for the factory to provide ambiguous >>> > methods. >>> >*/ >>> > setFactory(F factory); >>> > } >>> > >>> > You might wind up with code like… >>> > >>> > @Inject >>> > public MyWidget(MyUiBinder binder) extends Composite { >>> > >>> > public interface MyUiBinder extends UiBinderWithFactory>> MyWidget, >>> > MyGinjector> { >>> > @Inject setFactory(MyGinjector factory); >>> > } >>> > >>> > …and a few extra getters on your Ginjector. >>> > >>> > Now injecting an injector is generally a terrible idea, but it's >>> something >>> > at least. (Does that even work in Gin? And can you put @Inject on an >>> > interface method?) >>> > What do you think? >>> > rjrjr >>> > >>> > --
[gwt-contrib] Re: PUBLIC: Fix compile errors in user/build.xml compile.tests target. (issue749801)
LGTM http://gwt-code-reviews.appspot.com/749801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] PUBLIC: Fix compile errors in user/build.xml compile.tests target. (issue749801)
Reviewers: Ray Ryan, Description: PUBLIC: Fix compile errors in user/build.xml compile.tests target. Please review this at http://gwt-code-reviews.appspot.com/749801/show Affected files: M user/build.xml Index: user/build.xml === --- user/build.xml (revision 8505) +++ user/build.xml (working copy) @@ -109,6 +109,7 @@ location="${gwt.tools.lib}/selenium/selenium-java-client-driver.jar" /> location="${gwt.tools}/redist/json/r2_20080312/json-1.5.jar" /> + location="${gwt.tools.lib}/javax/validation/validation-api-1.0.0.GA.jar" /> -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r8510 committed - Recommiting the new CrossSiteIframeLinker....
Revision: 8510 Author: sp...@google.com Date: Tue Aug 10 07:06:57 2010 Log: Recommiting the new CrossSiteIframeLinker. This linker works cross-site, because it uses a script tag to download code instead of XHR. However, like the iframe linker, it still uses an iframe to hold all the installed code. This version adds a head element to the inner iframe if one is not already present. Review at http://gwt-code-reviews.appspot.com/726802 Review by: j...@google.com http://code.google.com/p/google-web-toolkit/source/detail?r=8510 Added: /trunk/dev/core/src/com/google/gwt/core/linker/CrossSiteIframeLinker.java /trunk/dev/core/src/com/google/gwt/core/linker/CrossSiteIframeTemplate.js /trunk/user/src/com/google/gwt/core/CrossSiteIframeLinker.gwt.xml /trunk/user/src/com/google/gwt/core/client/impl/CrossSiteIframeLoadingStrategy.java /trunk/user/test/com/google/gwt/core/ext/CrossSiteIframeLinkerTest.gwt.xml /trunk/user/test/com/google/gwt/core/ext/test/CrossSiteIframeLinkerTest.java /trunk/user/test/com/google/gwt/dev/jjs/CompilerSuiteCrossSiteIframe.gwt.xml /trunk/user/test/com/google/gwt/dev/jjs/CrossSiteIframeRunAsyncFailure.gwt.xml /trunk/user/test/com/google/gwt/dev/jjs/CrossSiteIframeRunAsyncMetrics.gwt.xml /trunk/user/test/com/google/gwt/dev/jjs/CrossSiteIframeRunAsyncSuite.java /trunk/user/test/com/google/gwt/dev/jjs/test/CrossSiteIframeRunAsyncFailureTest.java /trunk/user/test/com/google/gwt/dev/jjs/test/CrossSiteIframeRunAsyncMetricsTest.java /trunk/user/test/com/google/gwt/dev/jjs/test/CrossSiteIframeRunAsyncTest.java Modified: /trunk/user/src/com/google/gwt/core/Core.gwt.xml /trunk/user/test/com/google/gwt/core/ext/LinkerSuite.java === --- /dev/null +++ /trunk/dev/core/src/com/google/gwt/core/linker/CrossSiteIframeLinker.java Tue Aug 10 07:06:57 2010 @@ -0,0 +1,158 @@ +/* + * Copyright 2010 Google Inc. + * + * Licensed under the Apache License, Version 2.0 (the "License"); you may not + * use this file except in compliance with the License. You may obtain a copy of + * the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT + * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the + * License for the specific language governing permissions and limitations under + * the License. + */ + +package com.google.gwt.core.linker; + +import com.google.gwt.core.ext.LinkerContext; +import com.google.gwt.core.ext.TreeLogger; +import com.google.gwt.core.ext.linker.CompilationResult; +import com.google.gwt.core.ext.linker.LinkerOrder; +import com.google.gwt.core.ext.linker.Shardable; +import com.google.gwt.core.ext.linker.LinkerOrder.Order; +import com.google.gwt.core.ext.linker.impl.SelectionScriptLinker; +import com.google.gwt.dev.About; +import com.google.gwt.dev.js.JsToStringGenerationVisitor; +import com.google.gwt.dev.util.DefaultTextOutput; +import com.google.gwt.dev.util.TextOutput; +import com.google.gwt.dev.util.Util; + +/** + * This linker uses an iframe to hold the code and a script tag to download the + * code. It can download code cross-site, because it uses a script tag to + * download it and because it never uses XHR. The iframe, meanwhile, makes it + * trivial to install additional code as the app runs. + */ +...@linkerorder(Order.PRIMARY) +...@shardable +public class CrossSiteIframeLinker extends SelectionScriptLinker { + @Override + public String getDescription() { +return "Cross-Site-Iframe"; + } + + @Override + protected String generateDeferredFragment(TreeLogger logger, + LinkerContext context, int fragment, String js) { +StringBuilder sb = new StringBuilder(); +sb.append("$wnd."); +sb.append(context.getModuleFunctionName()); +sb.append(".runAsyncCallback"); +sb.append(fragment); +sb.append("("); +sb.append(JsToStringGenerationVisitor.javaScriptString(js)); +sb.append(");\n"); +return sb.toString(); + } + + @Override + protected byte[] generatePrimaryFragment(TreeLogger logger, + LinkerContext context, CompilationResult result, String[] js) { +// Wrap the script code with its prefix and suffix +TextOutput script = new DefaultTextOutput(context.isOutputCompact()); +script.print(getModulePrefix(context, result.getStrongName(), js.length > 1)); +script.print(js[0]); +script.print(getModuleSuffix(logger, context)); + +// Rewrite the code so it can be installed with +// __MODULE_FUNC__.onScriptDownloaded + +StringBuffer out = new StringBuffer(); +out.append(context.getModuleFunctionName()); +out.append(".onScriptDownloaded("); + out.append(JsToStringGenerationVisitor.javaScriptString(script.toString())); +out.append(")"); + +return Util.getBytes(out.toString()); + } + + @Override + protected String getCompila
Re: [google-gin] Re: [gwt-contrib] RR: What if UiBinder could take a factory?
On Tue, Aug 10, 2010 at 9:04 AM, Peter Schmitt wrote: > Hi all, > > this topic comes up so often that we should really find a solution. :) The > short story is that we might need to fix this issue but could potentially > work without it: > http://code.google.com/p/google-gin/issues/detail?id=95(Allow classes created > by a Generator to participate in dependency > injection) > > Long story: > > >> When you start creating multiple Ginjectors, instances of classes don't >> stay the > > same. For example, a Singleton EventBus in two Ginjectors are >> different instance types. >> > > If you inject your ginjector somewhere in its own dependency tree, it will > inject itself, i.e. it is automatically bound as a singleton. > > >> Also, I'm pretty sure you can't put an @Inject on an interface method, >> but I haven't tried. >> > > Yes, you can - this is explicitly allowed in Gin for use with Generators. > > > Would something like the following improve life for GIN users enough to >> be >> > worth doing? Or is it just a hack? >> > [...] >> > > I think this is perfectly viable - but we're running into the generator > interaction issue here. Right now, Gin cannot use generated code as input > and therefore will not be able to inspect the generated implementation of > MyUiBinder. This could be fine if we were specifying exactly what we want to > be injected into the factory. But as far as I can see, you're injecting the > ginjector and then using it in generated code. How do you know how to > retrieve objects from the Ginjector? In difference to Guice, there is *no > *getInstance(..) method on a Ginjector. > I think the scheme I sketched gets around this issue. Gin isn't aware of any of the generated code. Rather, the generated code is aware of the public Ginjector interface. When Gin is asked to inject a MyUiBinder, it's just going to write GWT.create(MyUiBinder), and then call that instance's setFactory() method with itself. So this code: @Inject public MyWidget(MyUiBinder binder) extends Composite { public interface MyUiBinder extends UiBinderWithFactory { @Inject setFactory(MyGinjector factory); } } makes Gin generate the moral equivalent of new MyWidget((MyUiBinder.class) GWT.create(MyUiBinder.class)).setFactory(this); Similarly, UiBinder is aware of the public interface of my public Ginjector. That's why the JavaDoc says that the factory is required to provide an explicit FooWidget getTheFoo() if it is to be a source of FooWidgets. You the developer put this method on your Ginjector: public interface MyGinjector extends Ginjector { FooWidget getFoo(); } And so UiBinder can generate something like: HTMLPanel h = new HTMLPanel("Blah di blah di blah di blah."); h.addAndReplaceElement(factory.getFoo(), "foo25"); Also, while I was assuming that for the most part the binder would be working off of the Ye One True Ginjector, there is no actual requirement that you do so, nor that your Factory be Ginjector at al. E.g.: @Inject public MyWidget(MyUiBinder binder) extends Composite { public static class Factory { @Inject @MagicScope EventBus eventBus; FooWidget makeAFoo() { return new Foo(eventBus); } } public interface MyUiBinder extends UiBinderWithFactory { @Inject setFactory(Factory factory); } } And if it's possible for one Ginjector to create another (haven't been paying attention, sorry), that boilerplate could perhaps be even less? @Inject public MyWidget(MyUiBinder binder) extends Composite { @MagicScope public interface Factory extends Ginjector { EventBus eventBus; } public interface MyUiBinder extends UiBinderWithFactory { @Inject setFactory(Factory factory); } } > I think what we want is a class generated by UiBinder that has @Inject > annotated constructor/fields/methods for its required children and is then > used as input by the Gin generator to wire the injection up. But to > accomplish that, we'll need to fix the issue mentioned above. > > How does this sound? > Like it would need a lot more thought and a lot more work :-). (Although it's a nicely DI-framework-agnostic notion, now that the annotations live in javax.). We really wouldn't just want limit you to putting @Inject on everything, you'd want the full gin experience — e.g. to be allowed to put other annotations on specific fields, right? All of a sudden we have to provide an annotation syntax for ui.xml. Don't get me wrong, I would rather fix GWT.create() so that Ginjector actually could efficiently provide a getInstance(...) method, and to allow gin to see generated code. But those two conversations never seem to terminate, and I don't have the chops to just do them myself. So my question is: if we accept the current limitations, would this change be a worthwhile incremental step? > > Peter > > > > >> > public interface UiBinderWithFactory extends UiBinder { >> > /** >> >* Sets a factory to use when instantiating objects that are not >> >* provi
[gwt-contrib] Re: Better error message on garbage in text. (issue748801)
http://gwt-code-reviews.appspot.com/748801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] devmode classloader retention
Thanks so much for digging into this, Stephen. @John, Bob, Ray: can you guys take a look at this and maybe create yourselves issues? It seems like this is a real performance issue, with the user ending up in sluggish performance or else having to restart DevMode, which is certainly slower than refresh. On Tue, Aug 10, 2010 at 1:32 AM, Stephen Haberman wrote: > > > Is the number of JRealClassType instances just going up and up each > refresh? > > Yep. I didn't explicitly check until you asked, but comparing heap diffs > before/after multiple refreshes, each refresh was adding ~1800 new > JRealClassTypes that never went away. > > > Can you figure out who is holding references to them (referrants)? > > Turns out I can. Thank you for the rather logical suggestion--I had > looked at the GC root paths and, once I saw AppClassLoader, had given up > thinking it was going to be an PITA classloader issue. > > But, no, its just some static caches. It took a few tries, but the > attached patch "fixes" the leaks and I can now run my whole test suite > and DevMode stays snappy. > > Note that I use the term "fixes" very loosely as: > > * ResourceFactory.cache just needs a WeakHashMap, pretty easy > > * OwnerFieldClass.FIELD_CLASSES needs a hash map that is weak on both > keys and values. Or some way to explicitly clear the values when > the TypeOracle is done with. > > I tried a WeakHashMap and it was not enough as the OwnerFieldClass > value is what holds the JRealClassType reference. What did work, was a > stupid, ugly hack of clearing the cache on each new oracle seen (which > is a bad idea, it would break multiple clients use DevMode > concurrently, but it proved the point). > > * AbstractResourceContext.CACHES is already a WeakHashMap, however, the > values end up being IdentityHashMaps with JRealClassTypes keys, which > reference the oracle, so, contrary to the javadoc, it does actually > keep TypeOracles from being GC'd. > > The same ugly hack from issue 2 also solved this final one. > > As my hacks obviously show, I don't know of a good way to deal with the > 2nd or 3rd issues. If you have a suggestion, I can try and run with it, > but I'd also be just fine with someone more knowledgeable about the > codebase finding an elegant solution. :-) > > Thanks! > > - Stephen > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Hard coded History integration for the Scaffold app. This is step zero (issue717801)
On Tue, Aug 10, 2010 at 6:40 AM, wrote: > > http://gwt-code-reviews.appspot.com/717801/diff/20002/33060 > File user/src/com/google/gwt/app/place/ProxyPlaceToListPlace.java > (right): > > http://gwt-code-reviews.appspot.com/717801/diff/20002/33060#newcode54 > user/src/com/google/gwt/app/place/ProxyPlaceToListPlace.java:54: public > ProxyListPlace go(Place place) { > Whats confusing is that it saves the record returned by > proxyPlace().getProxy(), and then I can get the record by calling > getProxy(). Its a stateful class, but I don't understand why. Do you > ever call ProxyPlaceToListPlace.getProxy()? This is an example of the over-complexity of this approach, which comes of trying to use a mechanism for apps that do one thing at a time for an app that is doing several at a time. Remember that the app can only be in one place at a time. The master list at the top of the screen needs to be shown with no selection when the app goes to a ProxyListPlace (it's the thing that shows the list of proxies). And it needs to stay visible and update its selection when the app moves to a ProxyPlace (to show the details for a single record). The list on the left side of the screen needs to maintain its selection in the same way. A ProxyPlaceToListPlace converter is able to tell you what list a particular proxy belongs to. An EmployeeRecord is in the EmployeeRecord.class list. When it figures that out for you, it also holds on to the proxy it looked at, e.g. to allow you to update your selection — getProxy(). You're right, though, that's a just plain odd side effect. It made more sense in an earlier, even more complicated version of this patch last week. I'll try to drop it before submitting. > > http://gwt-code-reviews.appspot.com/717801/diff/20002/33062 > File user/src/com/google/gwt/event/shared/EventBus.java (right): > > http://gwt-code-reviews.appspot.com/717801/diff/20002/33062#newcode45 > user/src/com/google/gwt/event/shared/EventBus.java:45: void > fireEvent(GwtEvent event); > There are probably a lot of people using it because all HasXXXHandlers > extend it. For example, HasClickHandlers extends it and adds > addBlurHandler. Oh, okay. Thanks. > > > http://gwt-code-reviews.appspot.com/717801/diff/20002/33070 > File user/src/com/google/gwt/user/client/ui/HasConstrainedValue.java > (right): > > http://gwt-code-reviews.appspot.com/717801/diff/20002/33070#newcode34 > user/src/com/google/gwt/user/client/ui/HasConstrainedValue.java:34: void > setValues(Collection values, Renderer render); > Assuming you mean for ImageLoadingCell, I think the renderers had more > to do with being able to customize loading and error messages than > building safe HTML. Either way, we'll need to take a look at how to > integrate the renderers in ImageLoadingCell with SafeHtmlBuilder, > because you can't just return an HTML string and call it unsafe. We > might need a SafeHtmlRenderer that takes a SafeHtmlBuilder instead of > returning a String. Yes. The main point is that a Renderer should strictly be used a source of plain user readable text, not nascent dom. > > > http://gwt-code-reviews.appspot.com/717801/show > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [google-gin] Re: [gwt-contrib] RR: What if UiBinder could take a factory?
> If you inject your ginjector somewhere in its own dependency tree, it will > inject itself, i.e. it is automatically bound as a singleton. Does this work if you have multiple Ginjectors? What I've done before was to have a hierarchy of Ginjectors and the top level one would be what gets instantiated. If you inject one of these Ginjectors lower in the hierarchy, would the instances still be the same? And sorry for my inaccurate info, my GWT is getting rusty :(. -- Arthur Kalmenson On Tue, Aug 10, 2010 at 12:04 PM, Peter Schmitt wrote: > Hi all, > this topic comes up so often that we should really find a solution. :) The > short story is that we might need to fix this issue but could potentially > work without it: http://code.google.com/p/google-gin/issues/detail?id=95 > (Allow classes created by a Generator to participate in dependency > injection) > Long story: > >> >> When you start creating multiple Ginjectors, instances of classes don't >> stay the >> >> same. For example, a Singleton EventBus in two Ginjectors are >> different instance types. > > If you inject your ginjector somewhere in its own dependency tree, it will > inject itself, i.e. it is automatically bound as a singleton. > >> >> Also, I'm pretty sure you can't put an @Inject on an interface method, >> but I haven't tried. > > Yes, you can - this is explicitly allowed in Gin for use with Generators. >> >> > Would something like the following improve life for GIN users enough to >> > be >> > worth doing? Or is it just a hack? >> > [...] > > I think this is perfectly viable - but we're running into the generator > interaction issue here. Right now, Gin cannot use generated code as input > and therefore will not be able to inspect the generated implementation of > MyUiBinder. This could be fine if we were specifying exactly what we want to > be injected into the factory. But as far as I can see, you're injecting the > ginjector and then using it in generated code. How do you know how to > retrieve objects from the Ginjector? In difference to Guice, there is no > getInstance(..) method on a Ginjector. > I think what we want is a class generated by UiBinder that has @Inject > annotated constructor/fields/methods for its required children and is then > used as input by the Gin generator to wire the injection up. But to > accomplish that, we'll need to fix the issue mentioned above. > How does this sound? > Peter > > >> >> > public interface UiBinderWithFactory extends UiBinder { >> > /** >> > * Sets a factory to use when instantiating objects that are not >> > * provided via @UiFactory methods or @UiField(provided = true) >> > fields. >> > * >> > * When an instance is needed, a zero args method with an appropriate >> > return type >> > * will be sought on the factory to provide it. If none is found >> > GWT.create() >> > * will be used instead. >> > * >> > * It is a compile time error for the factory to provide ambiguous >> > methods. >> > */ >> > setFactory(F factory); >> > } >> > >> > You might wind up with code like… >> > >> > @Inject >> > public MyWidget(MyUiBinder binder) extends Composite { >> > >> > public interface MyUiBinder extends UiBinderWithFactory> > MyWidget, >> > MyGinjector> { >> > �...@inject setfactory(MyGinjector factory); >> > } >> > >> > …and a few extra getters on your Ginjector. >> > >> > Now injecting an injector is generally a terrible idea, but it's >> > something >> > at least. (Does that even work in Gin? And can you put @Inject on an >> > interface method?) >> > What do you think? >> > rjrjr >> > >> > -- >> > http://groups.google.com/group/Google-Web-Toolkit-Contributors >> >> -- >> You received this message because you are subscribed to the Google Groups >> "google-gin" group. >> To post to this group, send email to google-...@googlegroups.com. >> To unsubscribe from this group, send email to >> google-gin+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/google-gin?hl=en. >> > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [google-gin] Re: [gwt-contrib] RR: What if UiBinder could take a factory?
Hi all, this topic comes up so often that we should really find a solution. :) The short story is that we might need to fix this issue but could potentially work without it: http://code.google.com/p/google-gin/issues/detail?id=95(Allow classes created by a Generator to participate in dependency injection) Long story: > When you start creating multiple Ginjectors, instances of classes don't > stay the same. For example, a Singleton EventBus in two Ginjectors are > different instance types. > If you inject your ginjector somewhere in its own dependency tree, it will inject itself, i.e. it is automatically bound as a singleton. > Also, I'm pretty sure you can't put an @Inject on an interface method, > but I haven't tried. > Yes, you can - this is explicitly allowed in Gin for use with Generators. > Would something like the following improve life for GIN users enough to be > > worth doing? Or is it just a hack? > > [...] > I think this is perfectly viable - but we're running into the generator interaction issue here. Right now, Gin cannot use generated code as input and therefore will not be able to inspect the generated implementation of MyUiBinder. This could be fine if we were specifying exactly what we want to be injected into the factory. But as far as I can see, you're injecting the ginjector and then using it in generated code. How do you know how to retrieve objects from the Ginjector? In difference to Guice, there is *no *getInstance(..) method on a Ginjector. I think what we want is a class generated by UiBinder that has @Inject annotated constructor/fields/methods for its required children and is then used as input by the Gin generator to wire the injection up. But to accomplish that, we'll need to fix the issue mentioned above. How does this sound? Peter > > public interface UiBinderWithFactory extends UiBinder { > > /** > >* Sets a factory to use when instantiating objects that are not > >* provided via @UiFactory methods or @UiField(provided = true) fields. > >* > >* When an instance is needed, a zero args method with an appropriate > > return type > >* will be sought on the factory to provide it. If none is found > > GWT.create() > >* will be used instead. > >* > >* It is a compile time error for the factory to provide ambiguous > > methods. > >*/ > > setFactory(F factory); > > } > > > > You might wind up with code like… > > > > @Inject > > public MyWidget(MyUiBinder binder) extends Composite { > > > > public interface MyUiBinder extends UiBinderWithFactory MyWidget, > > MyGinjector> { > > @Inject setFactory(MyGinjector factory); > > } > > > > …and a few extra getters on your Ginjector. > > > > Now injecting an injector is generally a terrible idea, but it's > something > > at least. (Does that even work in Gin? And can you put @Inject on an > > interface method?) > > What do you think? > > rjrjr > > > > -- > > http://groups.google.com/group/Google-Web-Toolkit-Contributors > > -- > You received this message because you are subscribed to the Google Groups > "google-gin" group. > To post to this group, send email to google-...@googlegroups.com. > To unsubscribe from this group, send email to > google-gin+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/google-gin?hl=en. > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RR: What if UiBinder could take a factory?
Hey Ray, Thanks for trying to make GIN user's lives easier when using UiBinder. However, injecting an injector wouldn't really work. Most GIN applications will end up having one top level Ginjector that would have a getter for some top level application widget. When you start creating multiple Ginjectors, instances of classes don't stay the same. For example, a Singleton EventBus in two Ginjectors are different instance types. Also, I'm pretty sure you can't put an @Inject on an interface method, but I haven't tried. -- Arthur Kalmenson On Mon, Aug 9, 2010 at 10:29 PM, Ray Ryan wrote: > If you don't use GIN (you know, that really should be GIn), the rest of this > note probably won't interest you. > Would something like the following improve life for GIN users enough to be > worth doing? Or is it just a hack? > > public interface UiBinderWithFactory extends UiBinder { > /** > * Sets a factory to use when instantiating objects that are not > * provided via @UiFactory methods or @UiField(provided = true) fields. > * > * When an instance is needed, a zero args method with an appropriate > return type > * will be sought on the factory to provide it. If none is found > GWT.create() > * will be used instead. > * > * It is a compile time error for the factory to provide ambiguous > methods. > */ > setFactory(F factory); > } > > You might wind up with code like… > > @Inject > public MyWidget(MyUiBinder binder) extends Composite { > > public interface MyUiBinder extends UiBinderWithFactory MyGinjector> { > �...@inject setfactory(MyGinjector factory); > } > > …and a few extra getters on your Ginjector. > > Now injecting an injector is generally a terrible idea, but it's something > at least. (Does that even work in Gin? And can you put @Inject on an > interface method?) > What do you think? > rjrjr > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Hard coded History integration for the Scaffold app. This is step zero (issue717801)
http://gwt-code-reviews.appspot.com/717801/diff/20002/33060 File user/src/com/google/gwt/app/place/ProxyPlaceToListPlace.java (right): http://gwt-code-reviews.appspot.com/717801/diff/20002/33060#newcode54 user/src/com/google/gwt/app/place/ProxyPlaceToListPlace.java:54: public ProxyListPlace go(Place place) { Whats confusing is that it saves the record returned by proxyPlace().getProxy(), and then I can get the record by calling getProxy(). Its a stateful class, but I don't understand why. Do you ever call ProxyPlaceToListPlace.getProxy()? http://gwt-code-reviews.appspot.com/717801/diff/20002/33062 File user/src/com/google/gwt/event/shared/EventBus.java (right): http://gwt-code-reviews.appspot.com/717801/diff/20002/33062#newcode45 user/src/com/google/gwt/event/shared/EventBus.java:45: void fireEvent(GwtEvent event); There are probably a lot of people using it because all HasXXXHandlers extend it. For example, HasClickHandlers extends it and adds addBlurHandler. http://gwt-code-reviews.appspot.com/717801/diff/20002/33070 File user/src/com/google/gwt/user/client/ui/HasConstrainedValue.java (right): http://gwt-code-reviews.appspot.com/717801/diff/20002/33070#newcode34 user/src/com/google/gwt/user/client/ui/HasConstrainedValue.java:34: void setValues(Collection values, Renderer render); Assuming you mean for ImageLoadingCell, I think the renderers had more to do with being able to customize loading and error messages than building safe HTML. Either way, we'll need to take a look at how to integrate the renderers in ImageLoadingCell with SafeHtmlBuilder, because you can't just return an HTML string and call it unsafe. We might need a SafeHtmlRenderer that takes a SafeHtmlBuilder instead of returning a String. http://gwt-code-reviews.appspot.com/717801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Faster edit-distance computation in JsFunctionClusterer (issue669801)
Hi Andre, I'm waiting on Ray C or Lex to give the LGTM, but I noticed this last patch you uploaded left out the editdistance library files. On Mon, Aug 9, 2010 at 4:48 PM, wrote: > > http://gwt-code-reviews.appspot.com/669801/diff/33001/34006 > File dev/core/src/com/google/gwt/dev/jjs/impl/JsFunctionClusterer.java > (right): > > http://gwt-code-reviews.appspot.com/669801/diff/33001/34006#newcode43 > dev/core/src/com/google/gwt/dev/jjs/impl/JsFunctionClusterer.java:43: > Pattern.compile("function |[_a-zA-Z$][.$_a-zA-Z0-9]*=function"); > On 2010/08/06 02:12:25, cromwellian wrote: > >> This regex will incorrect match vtable declarations of the form: > >> _.name = function() { ... } > >> These prototype declarations cannot be re-ordered, so don't let it > > match a >> >> single '_' symbol. > > > Fixed. > > http://gwt-code-reviews.appspot.com/669801/show > -- Eric Z. Ayers Google Web Toolkit, Atlanta, GA USA -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Allows Linkers to mark themselves as shardable by including a (issue678802)
close me http://gwt-code-reviews.appspot.com/678802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors