[gwt-contrib] Re: DockLayoutPanel
I think it is reallay interesting: I've been able to realize flexible and fluid layout before passing to use GWT, by using CSS and a combination of properties "position: absolute;" "top:xxx", "bottom;xxx", "width:xxx" etc. and I liked this approach because it does not use tables! In gwt, I've tried to do the same by using AbsolutePanel but it was not posible mainly because AbsolutePanel ony let you to set top and left value, (and, if I remember correctly, only as integer value). I don't know if it could be of any help, but here I want to give you a sample (in html) which I wrote while studing how to apply this kind of CSS layouts in GWT (for sure it works on IE7, I don't know if it works on IE6 but it was not important for me): {{{ Left Left Top Left Left Bottom Left Right Top Left Right Bottom Top Left Left Right Bottom Top Right Left Right Bottom Bottom Right Left Right Right }}} I would like to be able to reproduce such a layout in GWT. NB. Any news on UiBinder? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Injecting instances from generators to generated code.
A common situation using generators is write instantiation code to "inject" instances of non-generated classes. For example: String newFooExpr(String name){ return "new " + Foo.class.getName() + "(" + name + ")"; } String initializationExpr(Class cls, String varName, String expr){ return cls.getName() + " " + varName + " = " + expr; } String fooReferenceExpr = "foo"; String fooInitializacionExpr = initializationExpr(Foo.class, fooReferenceExpr, newFooExpr("hello")); Later, fooInitializationExpr is injected in the generated source code. This approach is easy to write for light object trees, but becomes complex with deep trees. Since serialization is a way to freeze an object tree for further consumption, such mechanism could be used to inject instances from generators to generated code. For example, being Foo serializable, and having an InstancePool in GeneratorContext: Foo foo = new Foo("hello"); String fooReferenceExpr = generatorContext.getInstancePool().add(foo); InstancePool.add() adds an instance to the pool and returns a generated global reference name. When all the generators were invoked, the InstancePool is serialized in a static context, where the instances can be referenced by generated reference names. This approach could allow frameworks like GIN to be fully compatible with Guice Modules, enabling injection of instances, scopes, etc.. How silly is this idea? Thanks in advance. - Andrés --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Injecting instances from generators to generated code.
On Sat, Jun 27, 2009 at 8:57 AM, Andrés Testi wrote: > Since serialization is a way to freeze an object tree for further > consumption, such mechanism could be used to inject instances from > generators to generated code. For example, being Foo serializable, and > having an InstancePool in GeneratorContext: > > Foo foo = new Foo("hello"); > > String fooReferenceExpr = generatorContext.getInstancePool().add(foo); > > InstancePool.add() adds an instance to the pool and returns a > generated global reference name. When all the generators were invoked, > the InstancePool is serialized in a static context, where the > instances can be referenced by generated reference names. > > This approach could allow frameworks like GIN to be fully compatible > with Guice Modules, enabling injection of instances, scopes, etc.. > > How silly is this idea? > You cannot necessarily instantiate client code inside the generator. For example, if it has native methods some JVMs will die with a linker error the instant you try and instantiate the class if it can't load a library with the native methods. Also, you can't deserialize the Java object's representation inside the generated code, so you would have to take the instance and generate code to initialize it in the generated code. Also, for JRE classes in particular but others as well, the JS implementations can be rather different than the Java versions, so the serialized form of the Java object running in the generator may be unrelated to what would be running in the GWT app. Note also that the arguments necessary to give to the constructor cannot be determined from the instance in general, so it isn't clear how this could work at all. You could have a builder class which records constructor arguments and builds up the generated Java expression (and would accept other builders for those arguments), but it isn't clear that buys a whole lot. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: SoyLite
On Fri, Jun 26, 2009 at 3:20 PM, Lex Spoon wrote: > I've been trying to think of ways to speed up the -soyc option, and > here is the result of one attempt. What do people think? > > The idea is to mimick some aspects of the speedy symbolMaps files. > Instead of using the enhanced SourceInfo's to track links between > before-optimization and after-optimization code, bill size information > only to the program as it stands at the end of Java optimization. > Additionally, be careful to avoid needing any massaging of the data > in StoryRecorder; instead, make a single pass through all > the size information. > How much would it be skewed by JS-level optimizations? What about JSNI code? -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on LightweightCollections in google-web-toolkit
Comment by cromwellian: One of the nice things about immutability is if the compiler can prove it, you can avoid alias-analysis for those objects, which enables better copy-propagation/cse as well as equational-reasoning. Without it, any method call or store to a reference of the same type has to be treated as potentially mutating the value of a variable, which limits code motion. Equational reasoning allows you to hoist out values of fields without worry, effectively allowing you to intercept constructor calls at compile time, and propagating constructing parameters around as constants. That is, code like `new Integer(10)` can simply replace any call to `Integer.intValue()` with `10`. For more information: http://code.google.com/p/google-web-toolkit/wiki/LightweightCollections --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---