Thanks Thomas for clearification. I managed to make my code properly
and to work :)
Here is method declaration in interface:
@Path("fields")
ListEditor<Fields, LeafValueEditor<Fields>> getFieldsEditor();
and here is implementation:
@Override
public ListEditor<Fields, LeafValueEditor<Fields>> getFieldsEditor()
{
return HasDataEditor.of(fields);
}
Of course, instead of returning new DataEditor every time, we should
move HasDataEditor.of(fields) to somewhere else in code, and in
getFieldsEditor() just return variable
that was assigned before.
Thanks again, hope that this will help to someone else.
On Jan 31, 5:42 pm, Thomas Broyer <t.bro...@gmail.com> wrote:
> On Monday, January 31, 2011 3:31:35 AM UTC+1, Milan Cvejic wrote:
>
> > /* This is a part where i have problems */
> > @Path("fields")
> > IsEditor<ListEditor<Label, Editor<Label>>> getFieldsEditor();
>
> Keep in mind that the Editor framework is based on code generation, which
> means it depends on code inspection (kind of reflection, but at
> compile-time).
>
> Here, you tell the generator that you'll use an Editor<> of Label objects,
> but which editor exactly? is it a LeafValueEditor<Label> (and it'll generate
> the appropriate calls to setValue on edit and getValue on flush)? is it a
> ValueAwareEditor<Label> (and it'll generate the appropriate calls to
> setValue, setEditorDelegate, and flush)? is it an HasEditorDelegate (and
> it'll generate the appropriate calls to setEditorDelegate)? is it a
> HasEditorErrors (and it'll generate the appropriate calls to showErrors)?
> has it sub-editors (and which ones? so it can generate the appropriate code
> to populate and then flush them)?
>
> (note that his is also why people often don't get the Editor framework
> working with interfaces: they don't declare their sub-editors in the
> interface, and/or add more sub-editors, and/or implement a few other
> "special" interfaces on the implementation class; and they wonder why the
> Editor framework doesn't see them).
>
> In other words, you have to replace Editor<Label> with a more precise type;
> ideally the exact editor you'll use (e.g. MyLabelEditor) but a more general
> type (e.g. LeafValueEditor<Label>) can be used if you want more "loose
> coupling" (but then beware: if your "runtime" editor implements any other
> "special" interface –e.g. HasEditorErrors– that is not declared in the
> parent editor, they won't be "seen" by the Editor framework).
>
> Now as for the implementation of your method, for a CellList, use a
> HasDataEditor.of(myCellList) (but it's best to, generally lazily, only build
> one instance of HasDataEditor for your CellList and then always return it,
> rather than creating a new hasDataEditor instance each time getFieldsEditor
> is called)
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment