Issue 19 and validation/decoration follow up

5 views
Skip to first unread message

Kenneth Westelinck

unread,
Feb 27, 2008, 3:13:22 AM2/27/08
to uf...@googlegroups.com
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.
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 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.
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.

Tell me what you think.


regards,

Kenneth

Tom

unread,
Feb 27, 2008, 5:02:38 AM2/27/08
to uface


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

Kenneth Westelinck

unread,
Feb 27, 2008, 5:16:12 AM2/27/08
to uf...@googlegroups.com
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);
- I would like the interceptor mechanism not to be constrained to decorators. So I would propose to add a shouldProcess(Component ...) method on the interceptor level.
- I  would propose to add a getDecoratorInfo method instead of  getDecoratorControlPosition on the DecoratingInterceptor.

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.
Cool!
 
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.
Yes, I thought this might already be possible. I haven't explored the whole API yet. Using UFaceObservables is indeed the way to go.
 
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
Agreed, but we need to keep it in mind. First finish the milestone for the API, then add nice to have stuff like ManagedForms. When do you want to achieve this first milestone by the way?

Do you want me to continue work on the Validation / Decoration part, so you guys can concentrate on other stuff? I will also look further into the Converter stuff.

Tom

unread,
Feb 27, 2008, 5:55:19 AM2/27/08
to uface


On 27 Feb., 11:16, "Kenneth Westelinck" <kenneth.westeli...@gmail.com>
wrote:
> > 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);
>
> - I would like the interceptor mechanism not to be constrained to
> decorators. So I would propose to add a shouldProcess(Component ...) method
> on the interceptor level.

+1

> - I would propose to add a getDecoratorInfo method instead of
> getDecoratorControlPosition on the DecoratingInterceptor.

+1

>
> 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.
>
> Cool!
>
> > 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.
>
> Yes, I thought this might already be possible. I haven't explored the whole
> API yet. Using UFaceObservables is indeed the way to go.

I've only started on the UFaceObservables and there's not too much
code there yet :-)

>
> > 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
>
> Agreed, but we need to keep it in mind. First finish the milestone for the
> API, then add nice to have stuff like ManagedForms. When do you want to
> achieve this first milestone by the way?

Sure ;-)

>
> Do you want me to continue work on the Validation / Decoration part, so you
> guys can concentrate on other stuff? I will also look further into the
> Converter stuff.

That would be great :-) I tried to get the decoration stuff working on
Swing yesterday but
haven't come to a conclusion yet how to do it (See http://www.pushing-pixels.org/?p=68).
I like the JXLayer solution because it doesn't require subclassing but
was hit hard by the
Java 1.4 constraint I set up. I'll need to take a closer look tonight.
Afterwards I'd like to
work on the MyGWT implementation.

Tom

Kenneth Westelinck

unread,
Feb 27, 2008, 8:13:41 AM2/27/08
to uf...@googlegroups.com
That would be great :-) I tried to get the decoration stuff working on
Swing yesterday but
haven't come to a conclusion yet how to do it (See http://www.pushing-pixels.org/?p=68).
I like the JXLayer solution because it doesn't require subclassing but
was hit hard by the
Java 1.4 constraint I set up. I'll need to take a closer look tonight.
Afterwards I'd like to
work on the MyGWT implementation.
Hmmm, according to my colleague decorations is part of standard Swing. I suggest, if you are willing and have some time :), to check out the latest svn/trunk from Spring RCP. The part responsible for decorating the widgets is: OverlayValidatingInterceptor. If you can't find it, I'll take a look at it tonight, I already have the source checked out :)

Tom

unread,
Feb 27, 2008, 9:11:58 AM2/27/08
to uface
On 27 Feb., 14:13, "Kenneth Westelinck" <kenneth.westeli...@gmail.com>
wrote:
Well they use JLayeredPane as far as I can see. I've read
http://www.pushing-pixels.org/?p=99.
This article holds 2 interesting informations:
- use JLabel for each Control decorated (inside the text which would
be fairly easy for us)
- use http://rabbit-hole.blogspot.com/2006/04/decoratingoverpainting-swing.html

I need to take a look at https://validation.dev.java.net/. Why solving
problems other have already solved
for us.

Your question about a first Milestone. My target for an Milestone with
working Swing, SWT/JFace, MyGWT was EclipseCon in Santa Clara
but for now to me it looks like we can't make it.

Tom

Tom

unread,
Feb 28, 2008, 11:14:33 AM2/28/08
to uface
Kenneth would you like to become a committer on UFacekit?

We need excellent programmers like you. If you'd like to become one
the only
thing required is to agree to our Commiter agreement [1] by replying
to this mail
stating that you read and understood the agreement. Afterwards I could
grant you
commit-rights on our SVN-Repository. If you don't want to no problem
then we could work together like we do already.

Tom

[1]http://code.google.com/p/uface/wiki/CommitterAgreement

Kenneth Westelinck

unread,
Feb 28, 2008, 11:51:51 AM2/28/08
to uf...@googlegroups.com
Tom,

Yes, I would be honored to work as a commiter on the UFace toolkit. If time, and my girlfriend, permits, I will spend some free time on fixing bugs and adding features.
In fact, I will be giving a short presentation on the UFace toolkit for my colleagues in the near future :)
Yes, I have read and understood the Commiter agreement (http://code.google.com/p/uface/wiki/CommitterAgreement).

Thanks for your trust.


regards,

Kenneth

Tom

unread,
Feb 28, 2008, 2:52:59 PM2/28/08
to uface
On 28 Feb., 17:51, "Kenneth Westelinck" <kenneth.westeli...@gmail.com>
wrote:
> Tom,
>
> Yes, I would be honored to work as a commiter on the UFace toolkit. If time,
> and my girlfriend, permits, I will spend some free time on fixing bugs and
> adding features.

Don't worry about time we all first have to do our day job and if time
permits we contribute
to such nice things like uface, eclipse, ...

> In fact, I will be giving a short presentation on the UFace toolkit for my
> colleagues in the near future :)

Great. I hope the toolkit is more feature complete by then, we are a
fairly young project ~3 months.

> Yes, I have read and understood the Commiter agreement (http://code.google.com/p/uface/wiki/CommitterAgreement).
>
> Thanks for your trust.

No problem. I've added you to the project members. Could test the SVN-
Commit (e.g. check in some white space change)
and report success/failure?

Tom

Kenneth Westelinck

unread,
Feb 28, 2008, 3:26:52 PM2/28/08
to uf...@googlegroups.com
No problem. I've added you to the project members. Could test the SVN-
Commit (e.g. check in some white space change)
and report success/failure?
Success! Relocated my repository and made first commit. Thanks.
Reply all
Reply to author
Forward
0 new messages