[gwt-contrib] Comment on CodeSplitting in google-web-toolkit
Comment by m.zdila: @br: We can compile together the client code for all the current modules, but it would not be very OSGi conforming. For example, imagine that some client bought our product including only some of the modules. It would not be very clean to include client code for all the existing modules as one monolithic build. Even if we gave him only the client code for the bundles he bought, then if he would buy additional bundle(s) and dynamically install it to the running system, there would be no chance to add the additional client side part to the existing monolithic build. Simply, each server-side user bundle should have its client module counterpart so they can be dynamically added/removed without recompiling (all) the client. Currently, as described in my first post, the shared workspace code gets duplicated. And exactly this is what makes traversing between modules slow - the JS code must be dowloaded every time (if not cached), parsed, and the workspace initialization code must be run. This way the monolithic build give us the opposite of the desired speed improvement. I admin that I don't know much about the optimization internals. Despite of that I dare to imagine that (in a near future) it would be possible the common workspace module to be separated from the view modules. The optimization can stay within the single module (build). The interface between workspace and view is governed by the Java interfaces (or maybe even the classes) and so the compiler can take it to the accound when optimizing. I personally would rather have this functionality even if the code would not be as much optimal as possible ;-). In any case, currently we can live just OK with our current solution. Good luck! For more information: http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on CodeSplitting in google-web-toolkit
Comment by cromwellian: The problem is, if you support separate compilation, the compiler can no longer make assumptions about which methods in your code base are 'live' (are going to be called) and which are 'dead' (are never called), it would be forced to include them on the chance that they might be called in the future by some third party module. This would massively bloat the size of the JS output as well as hamper other optimizations like inlining which depend on knowing things like that if an interface I is implemented by classes A and B, and B is never used, than I == A. This comes up frequently with say, List/ArrayList/LinkedList where LinkedList is rarely if ever used. In my opinion, what you really want is some kind of message bus or RPC mechanism, so that differently compiled packages can communicate over some interface. In this case, the amount of shared code that must be replicated can be kept to a minimum. For more information: http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on CodeSplitting in google-web-toolkit
Comment by m.zdila: cromwellian: I don't understand how could the RPC solve my problem. Maybe what I would like to have is currently very complicated in the GWT. I am accepting it and can live with that. Long time ago I was using DOJO and I was dynamically loading the views to the workspace. I know it has nothing to do with the GWT, I only want to tell you that some other frameworks can do it. (Un)fortunately I wouldn't use any JS-only framework even if it had such an feature :-). Anyway it would be great if GWT had some means to do the true dynamic code loading. It doesn't have to be necessairly transparent for the developer. I wouldn't mind to somehow explicitly mark some code interface points or something... For more information: http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on CodeSplitting in google-web-toolkit
Comment by hauke.kopf: We are also searching for solution to dynamically extend the GUI produced via GWT. Regarding Cromwellian's comment about the compiler optimizations and the static analysis of what code parts are live or dead, I would say that what we want is something like JARs for GWT. Have the base GWT application compiled as one or more JAR-like packages, develop you extensions/plugins against the main application's API and package them as JAR-like files. At runtime of course you as the application owner must make sure that all required JARs/bundles are present. But hey, that's exactly what people know from JAVA apps. If you miss a JAR file you will get a ClassNotFoundException. For more information: http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Reduction of JavaScript class declarations.
Makes sense. I remember thinking along the same lines as Andrés, but getting rid of the empty ctor functions ( http://code.google.com/p/google-web-toolkit/wiki/ClassSetupAndInstantiationOptimization) will probably obviate it, as few if any classes have truly empty ctors. On Thu, Jul 2, 2009 at 7:09 PM, Scott Blum sco...@google.com wrote: Of course, if we go with the idea of hoisting Java constructors into the JavaScript constructor, that stops working. Speaking of which, we don't have to limit it to just classes with one live constructor... two different JS constructors can share the same prototype object. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5664 - Allows CSS @def declarations to be retrieved as a String in a CssResource
Author: zun...@google.com
Date: Fri Jul 3 08:33:45 2009
New Revision: 5664
Modified:
trunk/user/src/com/google/gwt/resources/client/CssResource.java
trunk/user/src/com/google/gwt/resources/rg/CssResourceGenerator.java
trunk/user/test/com/google/gwt/resources/client/CSSResourceTest.java
trunk/user/test/com/google/gwt/resources/client/deftest.css
Log:
Allows CSS @def declarations to be retrieved as a String in a CssResource
implementation. Detection was added for colliding class names and @def
names,
but you can dis-ambiguate them with the @ClassName() annotation.
Patch by: zundel
Review by: bobv
Modified: trunk/user/src/com/google/gwt/resources/client/CssResource.java
==
--- trunk/user/src/com/google/gwt/resources/client/CssResource.java
(original)
+++ trunk/user/src/com/google/gwt/resources/client/CssResource.java Fri
Jul 3 08:33:45 2009
@@ -32,9 +32,10 @@
* li{...@code String someClassName();} will allow the css class
* code.someClassName/code to be obfuscated at runtime. The function
will
* return the obfuscated class name./li
- * li{...@code primitive numeric type someDefName();} will allow access
to the
- * values defined by {...@literal @def} rules within the CSS file. The defined
- * value must be a raw number, a CSS length, or a percentage value.
+ * li{...@code primitive numeric type or String someDefName();} will allow
+ * access to the values defined by {...@literal @def} rules within the CSS
file.
+ * The defined value must be a raw number, a CSS length, or a percentage
value
+ * if it is to be returned as a numeric type.
* /ul
*
* p
Modified:
trunk/user/src/com/google/gwt/resources/rg/CssResourceGenerator.java
==
--- trunk/user/src/com/google/gwt/resources/rg/CssResourceGenerator.java
(original)
+++ trunk/user/src/com/google/gwt/resources/rg/CssResourceGenerator.java
Fri Jul 3 08:33:45 2009
@@ -115,6 +115,7 @@
*/
private final MapString, MapJMethod, String
classReplacementsWithPrefix;
private final Pattern classSelectorPattern =
Pattern.compile(\\.([^ :+#.]*));
+private final SetString cssDefs = new HashSetString();
private final SetString externalClasses;
private final TreeLogger logger;
private final SetJMethod missingClasses;
@@ -137,6 +138,11 @@
}
@Override
+public void endVisit(CssDef x, Context ctx) {
+ cssDefs.add(x.getKey());
+}
+
+@Override
public void endVisit(CssSelector x, Context ctx) {
String sel = x.getSelector();
@@ -193,6 +199,19 @@
@Override
public void endVisit(CssStylesheet x, Context ctx) {
boolean stop = false;
+
+ // Skip names corresponding to @def entries. They too can be
declared as
+ // String accessors.
+ ListJMethod toRemove = new ArrayListJMethod();
+ for (JMethod method : missingClasses) {
+if (cssDefs.contains(method.getName())) {
+ toRemove.add(method);
+}
+ }
+ for (JMethod method : toRemove) {
+missingClasses.remove(method);
+ }
+
if (!missingClasses.isEmpty()) {
stop = true;
TreeLogger errorLogger = logger.branch(TreeLogger.INFO,
@@ -231,6 +250,15 @@
}
}
+ static class DefsCollector extends CssVisitor {
+private final SetString defs = new HashSetString();
+
+@Override
+public void endVisit(CssDef x, Context ctx) {
+ defs.add(x.getKey());
+}
+ }
+
/**
* Collects all {...@code @external} declarations in the stylesheet.
*/
@@ -1212,8 +1240,8 @@
private boolean prettyOutput;
private MapJClassType, MapJMethod, String
replacementsByClassAndMethod;
private MapJMethod, String replacementsForSharedMethods;
- private MapJMethod, CssStylesheet stylesheetMap;
private JClassType stringType;
+ private MapJMethod, CssStylesheet stylesheetMap;
@Override
public String createAssignment(TreeLogger logger, ResourceContext
context,
@@ -1701,34 +1729,39 @@
NumberValue numberValue = def.getValues().get(0).isNumberValue();
-if (numberValue == null) {
- logger.log(TreeLogger.ERROR, The define named + name
- + does not define a numeric value);
- throw new UnableToCompleteException();
+String returnExpr = ;
+JClassType classReturnType = toImplement.getReturnType().isClass();
+if (classReturnType != null
+
java.lang.String.equals(classReturnType.getQualifiedSourceName())) {
+ returnExpr = \ +
Generator.escape(def.getValues().get(0).toString())
+ + \;
+} else {
+ JPrimitiveType returnType =
toImplement.getReturnType().isPrimitive();
+ if (returnType == null) {
+logger.log(TreeLogger.ERROR, toImplement.getName()
++ : Return type must be primitive type or String for
[gwt-contrib] [google-web-toolkit commit] r5665 - Edited wiki page through web user interface.
Author: galgwt.reviews
Date: Fri Jul 3 08:45:52 2009
New Revision: 5665
Modified:
wiki/CssResource.wiki
Log:
Edited wiki page through web user interface.
Modified: wiki/CssResource.wiki
==
--- wiki/CssResource.wiki (original)
+++ wiki/CssResource.wiki Fri Jul 3 08:45:52 2009
@@ -64,6 +64,31 @@
}
}}}
* Calling `small()` would return the value `1`.
+ * `...@def` rules can be accessed as a String as well. You can retrieve
the two definitions above with:
+{{{
+interface MyResources extends CssResource {
+ String small();
+ String black();
+}
+}}}
+* Calling `small()` returns 1px
+* Calling `black()` returns #000
+ * The Generator will not allow you to declare an `...@def` rule with the
same name as a class, unless you annotate method to retrieve the class with
the `...@classname` annotation.
+{{{
+...@def myIdent 10px;
+.myIdent {
+ ...
+}
+
+interface MyResources extends CssResource {
+ String myIdent();
+
+ @ClassName(myIdent)
+ String myIdentClass();
+}
+}}}
+* Calling `myIdent()` returns @def value 10px
+* Calling `myIdentClass()` returns the obfuscated class name
for .myIdent
== Runtime substitution ==
(*Working*)
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Add ArtificialRescue annotation to compiler
Ignore patch set 5; the change to JProgram.traverse() is necessary. http://gwt-code-reviews.appspot.com/46801/diff/5008/4010 File dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java (right): http://gwt-code-reviews.appspot.com/46801/diff/5008/4010#newcode1087 Line 1087: visitor.accept(new ArrayListJArrayType(allArrayTypes)); I remembered why this is necessary once I rebased derpc against these changes. It allows GenerateJavaScriptAst.endVisit(JArrayType) to correctly export symbol data for array types. http://gwt-code-reviews.appspot.com/46801 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on CssResource in google-web-toolkit
Comment by nick.bleibtrey: I cannot find this in the trunk? Where is it located? thanks nick For more information: http://code.google.com/p/google-web-toolkit/wiki/CssResource --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] deRPC review comments
- generally, there's several line-wrap changes; did you mean them? Some seem to be desirably shortening very long lines, but a few length lines (E.g. javadoc in JDeclaredType l104:106). Minor, though. - unqualified TODO at GenerateJavaAST:2980, what are you promising/offering to do here? But most of those changes seem to be subsumed in Scott's review comments, so I'll skip to that thread for others. Most of which he already covered. - Generically, I at least could use a lot more javadoc (or at least doc) in the compiler parts (dev/*/**.java). I'd like to see new code improve that, at least. - If we don't want to support ArtificialRescue, should we move it into an impl package? - bad indent in DynaTable.gwt.xml - CustomFieldSerializerValidator looks like checkstyle fixing; separate submit? - ProxyCreator:337, prexisting modulo your refactoring, but the logger message of seems sub-optimal to me. - the com.google.gwt.rpc.*Test2 family of tests seem poorly named. They may be adequately differentiated from the older suites by the package name, but I'm worried that e.g. searches for *Test.java will miss them unexpectedly... if you want a different name, can the suffix go before Test? E.g. maybe DeRpcTest? - IdentityValueCommand: the point to the methods here is just to finalize them? - CommandClientSerializationStreamWriter:73: am I reading that only arrays, default objects, and custom field serialized objects are put into identityMap? Should the check for presence in that map be deferred, if e.g. primitives aren't stored in it? - Pair: shouldn't there be a common place for this, outside the deRPC server context? - RPCServlet.java: Since we need matching e.g. X-GWT-Module-Base strings in multiple places, should we have a shared Constants class for them? - RPCServlet.java:182: I realize processCall() is small replicated code, but shouldn't we just have out be an OutputStream, and consult DUMP_PAYLOAD twice (before and after) so as to not replicate? - RPCServlet.java:270: javadoc doesn't match implementation; gzips for !local, regardless of size. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
