On 2012/06/11 14:30:14, sameb wrote:
Re: Using the immediate parent's editor instead of the root editor,
I'm not sure
about the change.
I can get behind using non-LeafValueEditor parent editors (ie, publish
to
'address' if 'address.bogus' is the path), but I don't think it makes
sense to
publish a child error to a LeafValueEditor (ie, not publishing to
'address.city'
if 'address.city.bogus' is the path). I'd rather continue traversing
up till we
find a non-LeafValueEditor to publish to.
My rationale is that LeafValueEditors aren't designed to have
children. If the
error path thinks it has a child, then the error path is broken, but I
don't
think we should risk breaking code further by pushing the error to
something
that isn't expected it. In my project's specific case, this would
break because
we consume EditorErrors on LeafValueEditors, and we'd end up showing
the child
error as if it came from the LeafValueEditor's widget, instead of as
an
"unhandled" error.
There are cases where you have a LeafValueEditor representing a "complex
object", and your editor you simple select one object among many
(ValueListEditor for instance). There can very well be an error inside
the selected object, and the LeafValueEditor should have the choice to
show it, dismiss it (hide it) or let it bubble up.
One could say you shouldn't have such a violation to begin with, but we
can't know upfront all the use cases.
Attaching such a violation to the top-level editor just seems wrong.
Actually, I haven't checked but we might very well have such a use case.
At a minimum, we definitely have been using editors for "complex
objects", and we used a ValueAwareEditor with subeditors rather than a
LeafValueEditor only to benefit from
RequestFactoryEditorDriver#getPaths().
See http://code.google.com/p/google-web-toolkit/issues/detail?id=6227
where I propose an alternate way of doing it, and we'd then use
LeafValueEditors for "complex objects", where we could very well (at
least theoretically) have violations on sub-paths.
Realistically, though, I'm not sure if it's necessary to do anything
at all.
The OGNL path is clearly bogus, and it may just be safer to plop the
errors
directly into the top-most Editor. Traversing the paths to find
correct Editors
can get pretty hairy. You can't just assume the parent is valid, the
path could
be 'address.bogus.superbogus', and there could be invalid indexes
involved
('address[0]'.city, 'address["key"].city', etc..).
Well, I don't really mind doing too much work when the data being
processed is bogus; and when it's not bogus and it requires a bit of
work to display "correctly", then it's my problem to choose between that
kind of data (close to the underlying model) and slower perfs, or
reworking the data to have better perfs (provided reworking the data is
cheaper than walking up the paths).
We actually do have a very similar case, that would be fixed by that
patch, where we do rewrite the error paths (based on
RequestFactoryEditorDriver#getpaths()) so we're certain their will be an
editor to collect/process/display them. What I can't tell is whether in
this situation we do have those "LeafValueEditor for complex objects"
(or current "ValueAwareEditors with sub-editors, in the absence of some
HasPathsEditor").
http://gwt-code-reviews.appspot.com/1727807/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
