[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 -~--~~~~--~~--~--~---
