On 27 Feb., 09:13, "Kenneth Westelinck" <
kenneth.westeli...@gmail.com>
wrote:
> Hi,
>
> I've seen you committed my patch with the main codebase. Thank you for that.
> The last comment in the issue, related to this patch, talked about polishing
> up code and adding features.
> I have indeed been thinking about this :)
> 1) The problem with the current intercept mechanism for adding decorations
> to UI components intercepts _everything_. IMHO it should be possible to
> create interceptors on a per field basis. So you should be able to register
> an interceptor on the form, that will only intercept 1 field. I am still
> thinking on how to do this. We should not pollute the InputField API and
> register them there. The pest solution would be to have some kind of
> interceptor registry that looks for interceptors for a certain field.
> The existing API can remain unchanged. So default behavior is to take the
> interceptor registered with the form.
I also thought about this. Why can't we define the following methods
on
StatusDecoratingInterceptor which allows users to customize it:
protected int getDecoratorControlPosition(UIFormControl); //
UIDecorator.DecoratorInfo.TOP_LEFT
protected boolean shouldDecorateControl(UIFormControl);
> 2) You talked about decorating other form controls and how to do this. In
> JFace (sorry, that's the only part I know best) decoration boils down to
> decorating a control. So whatever Control, Widget, ... is being decorated,
> the decorator just needs to get its hands on the control and then show() the
I already fixed this issue if you look at the code base :-) I haven't
tested but I think
it should work now we every control. The problem was that you casted
to UIInputField.
> decoration. Maybe we can add another interface "Decoratable" that will be
> implemented by Controls, Widgets, ... that allow themselves to be decorated.
> 3) It should also be possible to add decorations to, e.g. buttons. So you
> can't press a save button if the contents of the form is not valid. Maybe
> the observableMap stored on the form can solve this, but I am not sure, let
> me look into this.
I don't think this a decoration but as we already discussed some where
the one
could listen to the validation status of a Form and enable/disable the
button. This
could be done using UFaceObservables by the way.
> 4) In JFace it is possible to use a ManagedForm that holds a MessageManager
> reference. By sending messages to this MessageManager, you put decorations
> on top of the form holding a summary of errors for example. Personally, I
> need this extension. I am, however, uncertain whether this kind of feature
> is supported by the other UI toolkits (GWT, Swing, ...). So if we want to
> add this, we need to define an abstract top level interface on top of all UI
> kits.
I already thought about this but before adding new widget types we
need to finish
the current ones. If an implementation doesn't provide such a feature
we could easily:
a) Source in a lib that provides such a component
b) Write such a component our own
Tom