My work about Swing/SWT Binding Test and implementation

[Angelo zerr]

Hi,
I send you my work about Swing Binding.
I have not finish to comment my code (sorry) but I would like just show you my work
and my test. Tell me if my work please you.

org.ufacekit.ui.swing.databinding => Your project updated to manage another Swing binding
org.ufacekit.ui.swing.databinding.usecases => Project with test of Swing Binding.
org.ufacekit.ui.swtdatabinding.usecases => Project with test of SWT Binding.

I have created org.ufacekit.ui.swt.databinding.swt.SWTObservables class which extends
org.eclipse.jface.databinding.swt.SWTObservables to manage binding with Slider.

The class test.swt.properties.background BindBetweenSliderAndTextBackground
bind SWT Text background with 3 Sliders (R, G, B).

You have the same test with Swing.

Regards Angelo

[Tom Schindl]

Great. Thank you Angelo, will take a look in the evening.

Did you thought about submitting your Slider-implementation to Eclipse.

Simply open a bug against
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Platform&component=UI&short_desc=[Databinding]

Tom

[Angelo zerr]

Hi

> Great. Thank you Angelo, will take a look in the evening.

Cool!

> Did you thought about submitting your Slider-implementation to Eclipse.

No I have not though that. My implementation is very basic and I'm not sure that my code
is very good. I prefer test it with complex usecases before submit it.

I have Just on question about JFace Databinding. What is the role of the Realm?
I have tried to read documentation about Realm, but I don't understand.
Your Swing Realm implementation is finished or must it be changed?

Regards Angelo

2008/1/22, Tom Schindl <toms...@gmail.com>:

[Tom Schindl]

Well the purpose of the realm is to synchronize things from UI-Thread
to a potential worker (and the other way round).
You could e.g. update your model out-of the UI-thread (e.g. because
you'll because your
validation code is very expensive).

I'm not very skilled when it comes to Swing (haven't done any Swing
code for ages :-)
because the JFace MVC fitted better into my way of think (not to
mention that Swing 4 years
ago looked so ugly).

We need to recheck how the Eclipse-Databinding guys implemented those
and have to find the Swing
counterpart. You could as well ask at the eclipse.platform-newsgroup
and I'm sure one of the databinding
gurus will explain it to you (else I ask one I know one of the core devs ;-).

As of now the implementation can't deal with the situation that
something happens out of the UI-Thread
(and I think swing also has such a beast, right?)

Tom

[Tom Schindl]

> > Did you thought about submitting your Slider-implementation to Eclipse.
> No I have not though that. My implementation is very basic and I'm not sure
> that my code
> is very good. I prefer test it with complex usecases before submit it.
>

No need to hurry, still it would be great if you could contribute that up-stream
because this means we don't have to maintain it and those guys are really
helpful because they have indepth knowledge how SWT works :-)

[Angelo zerr]

Hi Tom,
Thank you for your information.
I was studied binding implementation of bean-properties project  before discover your project. Into the bean-properties binding implementation it use ThreadManager class. See the code at last my mail. If you see the code, there is SwingUtilities.invokeAndWait(r); code
where SwingUtilities is Swing class. I'm not expert into Swing but perhaps it's the SwingUtilities that we must use to implement correctly SwingRealm?

Angelo

public class ThreadManager {
    /**
     * Indicates the default manager used in the application this allows
     * developers to independently install their own "main thread" for the
     * application although this might not be a "good idea" unless you know what
     * you are doing...
     */
    public static final Property defaultInstance = PropertyImpl
            .create(new ThreadManager());

    /**
     * Contains all the threads that are supported by the manager, developers
     * interested in multithreading should add their ThreadManager into this
     * list of managers
     */
    public static final IndexedProperty managers = IndexedPropertyImpl.create();

    public ThreadManager() {
        BeanContainer.bind(this);
    }

    /**
     * <p>
     * Returns the thread manager to handle the given listener, a listener can
     * be distinguished by the appropriate subclass using marker interfaces,
     * annotations etc...
     * <p>
     * This method never returns null, it will return the default manager if
     * none of th installed managers fit the bill.
     */
    public static ThreadManager getManager(Object listener) {
        for (Iterator iterator = managers.iterator(); iterator.hasNext();) {
            ThreadManager manager = (ThreadManager) iterator.next();
             if(manager.isRightManager(listener)) {
                    return manager;
                }
           
        }
        return (ThreadManager)defaultInstance.get();
    }

    /**
     * This method should be overriden to indicate if this manager should be
     * used for a particular listener instance.
     */
    protected boolean isRightManager(Object listener) {
        return false;
    }

    /**
     * Invokes r on the thread represented by this manager and waits on the
     * current thread for r to complete. If the current thread is already the
     * destination (isRightThread() returns true) the behavior of this method is
     * undefined and it might fail/block forever.
     */
    public void invokeAndWait(Runnable r) {
        try {
            SwingUtilities.invokeAndWait(r);
        } catch (InterruptedException i) {
            // not much to do
            i.printStackTrace();
            return;
        } catch (InvocationTargetException err) {
            Throwable e = err.getCause();
            if (e instanceof RuntimeException) {
                throw (RuntimeException) e;
            }
            throw new BeanBindException((Exception) e);
        }
    }

    /**
     * Returns true if the current thread is the "right thread" for this type of
     * dispatch
     */
    public boolean isRightThread() {
        return SwingUtilities.isEventDispatchThread ();
    }
}

2008/1/22, Tom Schindl <toms...@gmail.com >:

[Angelo zerr]

Ok Tom I understand your opinion.
I will try to submit my work to Eclipse dev when I will have test Slider with complex cases.

Angelo

2008/1/22, Tom Schindl < toms...@gmail.com>:

[Tom Schindl]

Great. We are always trying to push things up (e.g. UBean is a
potential candidate too here, the current implementation is forked
from Bean-Implementation
but I'd like to fork it from EMFBinding-Instead because an UBean works
like an EObject :-)

Tom

[James Strachan]

This looks great stuff Angelo!

BTW how about adding the use cases into the test directories inside
the different modules?

I noticed lots of files didn't have any license header - can we make
sure all files have the EPL header please? I'll try fix up the maven
build so it reports missing headers...

I've added a page on Contributing...
http://code.google.com/p/uface/wiki/Contributing

see the bit at the bottom on becoming a committer. Here's the
committer agreement we'd like folks to agree to on the list to get
karma on the project (which is basically the same as the Apache
one)...
http://code.google.com/p/uface/wiki/CommitterAgreement

this may seem heavy handed :) its just so that the project runs like
an Apache or Eclipse project; that committers basically agree that all
their work is donated to the project as EPL code, its their own work
and as no IP violations and stuff. This will make things easier if in
the future we decided to move some of the code into Eclipse or Apache
or whatever - plus it protects us all.

Is that OK with you Angelo? Do you agree with the committer agreement
- if so we can grant you karma on the project.

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com

[Angelo zerr]

Hi James,

> BTW how about adding the use cases into the test directories inside
> the different modules?

You want add test package into each project. It seems good.
I have created User class model into each project. Perhaps it should b ebetter
to have core usecases Eclipse Project (to define User model one time) and after each Eclipse project
are linked to this project?

>I noticed lots of files didn't have any license header - can we make
>sure all files have the EPL header please? I'll try fix up the maven
>build so it reports missing headers...

Ok, I will change that. I'm sorry, I wanted to show my work but I have not finished to comment
my class file. Sorry, but I will do that if I can contribute.

> Is that OK with you Angelo? Do you agree with the committer agreement

I would like help UFace project because into Tk-UI I need binding. I prefer
work with UFace team to share our experience and idea than I develop my own databinding.
So if I can use UFace code into Tk-UI and Akrogen (It's LGPL license for Tk-UI and GPL for Akrogen), I'm agree
and I will happy to work with you.

For me I will prefer have rights into SVN (to avoid create SVN patch), but if I understand that it's very dangerous for you and perhaps you prefer that I create SVN patch. Tell me how you want we work together. My only aim is to have a wonderfull binding :)

If you want test TK-UI, tell me I could explain you how test it.

I have start to write OpenOffice documentation which explain my idea about DBEL (Data Binding Expression Language). If you have time to read it (sorry for my bad English, I'm frensh), I would like have your opinion.
The aim of DBEL is to manage DB with String (like MigLayout wher you can man,ag elayout with String).
It will very usefull after to manage binding into XML UI (like XAML).

Thank you.

Regards Angelo

2008/1/22, James Strachan <james.s...@gmail.com>:

[Tom]

Hi Angelo,

>
> I would like help UFace project because into Tk-UI I need binding. I prefer
> work with UFace team to share our experience and idea than I develop my own
> databinding.
> So if I can use UFace code into Tk-UI and Akrogen (It's LGPL license for
> Tk-UI and GPL for Akrogen), I'm agree
> and I will happy to work with you.
>

We want to give you SVN write access but to you give that you should
state that you agree
with the Committer agreement (an important thing for me is that you
state that it is YOUR work).
We'd really like to see your contributions in our lib. I'm not 100%
sure about all those license thingies.
James do we have to add an License Exception for GPL.

As far as I can remember EPL and GPL don't play nice together whereas
Apache and EPL are compatible.
I hate all those license stuff but I want to make sure from the
beginning that we do things right.

Tom

[James Strachan]

On 23/01/2008, Angelo zerr <angel...@gmail.com> wrote:
> Hi James,
>
> > BTW how about adding the use cases into the test directories inside
> > the different modules?
> You want add test package into each project. It seems good.

Yeah - am just thinking its easier to write the code and tests
together in the same module. It'd be great to have JUnit tests too one
day... I guess we could do the bindings, change the model then inspect
the (say) Swing widgets to determine if its displaying the right
stuff?

> I have created User class model into each project. Perhaps it should b
> ebetter
> to have core usecases Eclipse Project (to define User model one time) and
> after each Eclipse project
> are linked to this project?

Yeah. There's org.ufacekit.ui.example which is used for the examples;
I guess we could have a core test module to define common domain
models and test classes which is only used to create the concrete test
classes in each UI module etc?

> >I noticed lots of files didn't have any license header - can we make
> >sure all files have the EPL header please? I'll try fix up the maven
> >build so it reports missing headers...
> Ok, I will change that. I'm sorry, I wanted to show my work but I have not
> finished to comment
> my class file.

No worries :). Was just thinking longer term.

> Sorry, but I will do that if I can contribute.
>
> > Is that OK with you Angelo? Do you agree with the committer agreement
> I would like help UFace project because into Tk-UI I need binding. I prefer
> work with UFace team to share our experience and idea than I develop my own
> databinding.
> So if I can use UFace code into Tk-UI and Akrogen (It's LGPL license for
> Tk-UI and GPL for Akrogen), I'm agree
> and I will happy to work with you.
>
> For me I will prefer have rights into SVN (to avoid create SVN patch), but
> if I understand that it's very dangerous for you and perhaps you prefer that
> I create SVN patch. Tell me how you want we work together. My only aim is to
> have a wonderfull binding :)

:)

We'd love to grant you full karma so you can commit directly to SVN.
We're just asking folks to agree to the committer agreement (which
basically says every commit is donated to the project as EPL licensed
and there's no known IP issues with any code - i.e. its your code to
donate). Again we're just thinking longer term here; if some day some
of the code needs to move to Apache or Eclipse; having these
agreements in place saves loads of time & effort later on.

Once folks agree to the committer agreement, we can grant you commit access.

So do you agree with the agreement - if so we can grant you a committer?

> If you want test TK-UI, tell me I could explain you how test it.
>
> I have start to write OpenOffice documentation which explain my idea about
> DBEL (Data Binding Expression Language). If you have time to read it (sorry
> for my bad English, I'm frensh), I would like have your opinion.

BTW do you fancy hacking up a wiki document instead?
http://code.google.com/p/uface/w/list

> The aim of DBEL is to manage DB with String (like MigLayout wher you can
> man,ag elayout with String).
> It will very usefull after to manage binding into XML UI (like XAML).

Yeah - I think some kind of data binding expression language could
really help; particularly as one day we could use some markup to
create layouts and do the binding all using something like HTML/XML or
something.

I can even imagine using a GWT generator to take the HTML markup and
generate some client side JavaScript that avoids having to parse the
HTML and the binding expression language on startup.

[Angelo zerr]

> Yeah - am just thinking its easier to write the code and tests
> together in the same module. It'd be great to have JUnit tests too one
>day... I guess we could do the bindings, change the model then inspect
>the (say) Swing widgets to determine if its displaying the right
>stuff?

I think that we must think how organize project test today.
For me there is two test type :
* testcase : to test the code with JUnit.
* usecases : to show sample.

If you set test source into project org.ufacekit.ui.swing.databinding
and that test is linked with org.ufacekit.ui.example project (for Domain class...)
You can use the org.ufacekit.ui.swing.databinding without samples.
In my case, I would like use org.ufacekit.ui.swing.databinding project
without sample to test it with Tk-UI.
Perhaps it shoud be better to have usecases/testscase project and
org.ufacekit.ui.swing.databinding.usecases and source project
org.ufacekit.ui.swing.databinding?

> So do you agree with the agreement - if so we can grant you a committer?

I 'm agree with this agreement, but EPL license can be used with LGPL or GPL
license? If I can use UFace source in my project there is no problem.

>BTW do you fancy hacking up a wiki document instead?
>http://code.google.com/p/uface/w/list

I have not all the time Internet at home, so I prefer for the moment write
document into ODT. Sorry.
I don't know develop DBEL alone so I have written doc to share our experience and idea.
Have you read my document? What do you think about it?

>Yeah - I think some kind of data binding expression language could
>really help; particularly as one day we could use some markup to
>create layouts and do the binding all using something like HTML/XML or
>something.

>I can even imagine using a GWT generator to take the HTML markup and
>generate some client side JavaScript that avoids having to parse the
>HTML and the binding expression language on startup.

Wow! I like this idea.

Angelo

2008/1/23, James Strachan <james.s...@gmail.com>:

[James Strachan]

On 23/01/2008, Angelo zerr <angel...@gmail.com> wrote:
> > Yeah - am just thinking its easier to write the code and tests
> > together in the same module. It'd be great to have JUnit tests too one
> >day... I guess we could do the bindings, change the model then inspect
> >the (say) Swing widgets to determine if its displaying the right
> >stuff?
> I think that we must think how organize project test today.
> For me there is two test type :
> * testcase : to test the code with JUnit.
> * usecases : to show sample.

Yeah. Right now we have an examples project to show a demo of some UI.e.g.

useful example classes -
org.ufacekit.ui.example

GWT examples -
org.ufacekit.ui.gwt.example
org.ufacekit.ui.gwtext.example
org.ufacekit.ui.mygwt.example

The the swing and jface modules have examples in them (in the test area)
org.ufacekit.ui.jface
org.ufacekit.ui.swing
org.ufacekit.ui.swingx

I guess there's no reason why we couldn't have lots of little use case
/ examples in those projects. (The GWT modules are a tiny bit harder,
as we'll have a single entry point but need to put the examples in a
little tab or popup something)

So far the main reason I lumped use case/examples/test all together
into the test directory was to simplify the maven build. Maybe for use
cases we should split those into a separate project?

> If you set test source into project
> org.ufacekit.ui.swing.databinding
> and that test is linked with org.ufacekit.ui.example project (for Domain
> class...)
> You can use the org.ufacekit.ui.swing.databinding without
> samples.
> In my case, I would like use
> org.ufacekit.ui.swing.databinding project
> without sample to test it with Tk-UI.

Sounds good.

> Perhaps it shoud be better to have usecases/testscase project and
> org.ufacekit.ui.swing.databinding.usecases and source
> project
> org.ufacekit.ui.swing.databinding?

Yeah. I guess folks might want to reuse the usecases maybe? So a
separate module might make sense.

Given we've already got the *example modules, I wonder should we name
them org.ufacekit.ui.swing.databinding.example?

> > So do you agree with the agreement - if so we can grant you a committer?
> I 'm agree with this agreement

Awesome! :)

> , but EPL license can be used with LGPL or GPL
> license?

Yes! And Apache too.

> If I can use UFace source in my project there is no problem.

Great!

> >BTW do you fancy hacking up a wiki document instead?
> >http://code.google.com/p/uface/w/list
> I have not all the time Internet at home, so I prefer for the moment write
> document into ODT. Sorry.

No worries.

BTW the wiki documents are stored in subversion...
http://uface.googlecode.com/svn/wiki/

so you can check them all out when online, then hack them offline and
merge them back again when you get back online

> I don't know develop DBEL alone so I have written doc to share our
> experience and idea.
> Have you read my document? What do you think about it?

Haven't read it yet - will read it soon...

[James Strachan]

On 23/01/2008, James Strachan <james.s...@gmail.com> wrote:
> On 23/01/2008, Angelo zerr <angel...@gmail.com> wrote:
> > > So do you agree with the agreement - if so we can grant you a committer?
> > I 'm agree with this agreement
>
> Awesome! :)

I've added you as a committer to UFace! Welcome!

See if you can grab the code (using https) and make a commit...
http://code.google.com/p/uface/source

If that works, your commits should show up in the subversion mailing list...
http://groups.google.com/group/uface-notify

I've added a little page for committers to keep track if this kinda stuff...
http://code.google.com/p/uface/wiki/Committers

[Angelo zerr]

Thank you very much!
I will try to commit my source today or at end of this week.

For my usecases Swing et SWT project, if I have understand, you would like that I name like this :

org.ufacekit.ui.swing.databinding.example and org.ufacekit.ui.jface.databinding.example
That is it? and for package too (replace test package with org.ufacekit.ui.swing.databinding.example)?

And for the testcases, how can we do? I think it's better to have source project org.ufacekit.ui.swing.databinding (without link with example project or JUnit jar) and have project org.ufacekit.ui.swing.databinding.example which is linked to org.ufacekit.ui.example and perhaps JUnit. Can I add my User class model into the org.ufacekit.ui.example project?

Angelo

2008/1/23, James Strachan <james.s...@gmail.com>:

[James Strachan]

On 23/01/2008, Angelo zerr <angel...@gmail.com> wrote:
> Thank you very much!
> I will try to commit my source today or at end of this week.
>
> For my usecases Swing et SWT project, if I have understand, you would like
> that I name like this :
>
> org.ufacekit.ui.swing.databinding.example and
> org.ufacekit.ui.jface.databinding.example
> That is it? and for package too (replace test package with
> org.ufacekit.ui.swing.databinding.example)?

Yeah. So the org.ufacekit.ui.swing.databinding.example comes in the
src directory with a number of example programs you can run from the
main() methods etc.

> And for the testcases, how can we do? I think it's better to have source
> project org.ufacekit.ui.swing.databinding (without link
> with example project or JUnit jar) and have project
> org.ufacekit.ui.swing.databinding.example which is linked
> to org.ufacekit.ui.example and perhaps JUnit. Can I add my User class model
> into the org.ufacekit.ui.example project?

Yes.

The JUnit test cases can go in the test directories of the modules
that they test; so inside org.ufacekit.ui.swing.databinding to test
the swing data binding etc.

From the maven build perspective, there's a 'test scope' so we can add
dependencies, like junit which are only for building/running the test
cases and don't add any dependencies of making the src directory.
(There dependencies are then reflected down if we turn the jars the
build creates into OSGi bundles, which we should do...).

[Tom Schindl]

Welll in OSGi you could mark the test-dependencies as OPTIONAL this means
if the needed bits are available you can compile ;-) but for the sake
of simplicity
let's create seperate plugins for now.

Tom