Following constract seems pretty fragile and hard
to keep when evolving the implementation. Please
make it more robust by writing a verification check:
The PropertyEditor instance will already be
initialized with the initial value, and if it is
an instance of ExPropertyEditor,
ExPropertyEditor.attachEnv(env) will already have
been called. The PropertyEnv instance is passed
to allow rendering hints to be passed to the
Okay, not a problem. Re hard to keep, well it's mainly scoping
for the inplace editor - that the inplace editor will be
responsible for presentation of a property editor, and firing
changes that may be applied to it, but the infrastructure that
instantiates it is responsible for any calls that set the value
of the property editor, and that the inplace editor does not
decide when or how the value is actually set - it can only
communicate that it is ready for this to be done.
Value setting code for property editors should be centralized
so there is a single contract that can be evolved without forcing
changes in anybody's inplace editors.
Probably done in CustomInplaceEditorTest. Tim, can you set milestone
and tell me which test is doing this?
It's implicit in all of the tests - they cannot be tested without
being set to render a property correctly, which means connect() is
called. If connect is broken for an inplace editor, it will
definitely be caught by the test that fakes keyboard events.