I just tried my workaround on my real app and it actually doesn't work: the
BaseFooEditor_subEditor_Context class is generated based on the
parameterization of the first found instance so the following uses with
another parameterization don't compile. E.g.
public class BaseFooEditor_subEditor_Context extends
com.google.gwt.editor.client.impl.AbstractEditorContext<java.lang.String> {
private final *xxx.Foo* parent;
public BaseFooEditor_subEditor_Context(*xxx.Foo* parent,
com.google.gwt.editor.client.Editor<java.lang.String> editor, String path) {
super(editor,path);
this.parent = parent;
}
@Override public boolean canSetInModel() {
return parent != null && true && true;
}
@Override public java.lang.String checkAssignment(Object value) {
return (java.lang.String) value;
}
@Override public Class getEditedType() { return java.lang.String.class; }
@Override public java.lang.String getFromModel() {
return (parent != null && true) ? parent.getAuteurId() : null;
}
@Override public void setInModel(java.lang.String data) {
parent.setAuteurId(data);
}
}
Notice how it uses "xxx.Foo", from the BaseFooEditor<Foo> field in AEditor,
instead of BaseFoo (from the class BaseFooEditor<T extends BaseFoo>), which
makes it impossible to have a BaseFooEditor<Bar> elsewhere, and therefore
defeating the proposed workaround.
I believe it is a distinct bug however, but it makes it impossible to use a
ListEditor for a List<Foo> without having a FooEditor implements
Editor<Foo>(such as FooEditor
extends BaseFooEditor<Foo>, instead of just using BaseFooEditor<Foo> as I
proposed earlier).
In my case, because I have 4 different subclasses of BaseFoo means that I
need 4 new specialized editor classes (fortunately, and contrary to what I
wrote earlier, I don't have other such cases; i.e. no BaseBar, BaseBaz and
BaseQuux, but still).
And another blocking issue (it already hit us with 2.1.1, so it's not a
"regression" introduced with the recent editors overhaul): it generates
files with too long names. We had once, with 2.1.1, a 261 chars long
filename; because we used a specialized EditorDelegate class (as a
workaround for issue 5892), the workaround was to rename the class so the
generated class name falled below the limit.
Now with trunk@9715, because issue 5892 has been fixed, I have removed the
workaround, and I now have a similar errors (maybe the same actually):
[INFO] java.lang.RuntimeException: Error writing out generated unit at
'C:\Documents and Settings\tbr\My
documents\my-project\target\gwtc\gen\com\google\gwt\editor\client\CompositeEditor_java_util_List_xxx_FooProxy_xxx_FooEditor_RequestFactoryEditorDelegate.java'
…
[INFO] Caused by: java.io.FileNotFoundException: C:\Documents and
Settings\tbr\My
documents\my-project\target\gwtc\gen\com\google\gwt\editor\client\CompositeEditor_java_util_List_xxx_FooProxy_xxx_FooEditor_RequestFactoryEditorDelegate.java
(The filename, directory name, or volume label syntax is incorrect)
The real file name is 264 chars long. Note that most file systems limit
filenames to 255 bytes or UTF codepoints (which are the same here, as we
only use 7-bit ASCII):
http://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits
The only workaround I can think of is to remove the -gen argument to
Compiler, but then I no longer can see what's being generated (which I
happen to use to debug a few things, such as our use of editors...)
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
