UFaceKit implementation for Desktop based upon EMF

[Tom]

Hi,

Over at E4 we are discussing declarative UI. Those of you not
following today in the morning I posted a new way of UFaceKit-
Implementation for Desktop-Toolkits.

The main point is that I propose the following design:

UFaceKit-Interfaces
^
|
---------------------------------------
| |
ConstraintedDevice AbstractUFaceKitEcore
^ ^
| |
---------------------- -----------------------------
| | | | | |
Android eSWT GWT SWTEcore SwingEcore QTEcore

So instead of using our hand-crafted UControlBean and friends we will
use EMF and EObject as the base for the Desktop-Implementations. This
gives us direct access to all EMF-Enabled technologies in the desktop
env (e.g. serialization/deserialization, ....). From the outside the
usage of EMF is hidden through our UBean-API so there won't change
anything.

Any comments? If others think there's a need to have an SWT/Swing-
Implementation without an EMF-Dependency then they can work on it or
we could at a later point factor out the interfacing with SWT into
Delegates

Tom

[Angelo zerr]

Hi Tom,

I have read that into E4 forum.
I would like know what is the impact of this refactoring?

Must I have dependecies with EMF?
UBeanInterface will extends EObject?
UIControlbean will be removed?

My question is will able to use UFace without EMF?
If your answer is yes, that's very cool, but how it works?

Could we use the same factory (JFactory) for UBeanWithoutEMF and UBeanWithEMF?

Sorry Tom, it's difficult for me to understand your idea.

Angelo


2008/12/19, Tom <toms...@gmail.com>:

[Tom]

On 19 Dez., 11:28, "Angelo zerr" <angelo.z...@gmail.com> wrote:
> Hi Tom,
>
> I have read that into E4 forum.
> I would like know what is the impact of this refactoring?
>
> Must I have dependecies with EMF?
> UBeanInterface will extends EObject?

No maybe an example helps to clarify this a bit - Let's take UILabel
as an example.

Currently we have:
------------------
JFaceLabel (implements UILabel)
+ SWTControl
+ UIControlBean

In future it would be:
-----------------------
JFaceLabel (implements UILabel)
+ SWTControl
+ AbstractEcoreControl

So UIControlBean is not used anymore by implementations based the new
ecore-support the content we now have in UIControlBean is merged into
this new class.

> UIControlbean will be removed?

No but I'd favor to move it to a seperate package.

>
> My question is will able to use UFace without EMF?

Depends on the implementation you use - the core will be free from EMF
but the SWT implementation (at least the one I want to work on will
need it). I don't see a big problem in requiring 2 more jars. From the
outside you won't notice that the implementation is backed up by EMF.
The JFaceFactory will stay 100% as it is now. We only switch the
objects backing up the native control.

> If your answer is yes, that's very cool, but how it works?
>

See above if you want an EMF-Free version you'd need to continue the
work we've done until now. Do you see a problem in having an EMF-
Dependency in *Desktop* versions?

> Could we use the same factory (JFactory) for UBeanWithoutEMF and UBeanWithEMF?
>
> Sorry Tom, it's difficult for me to understand your idea.
>

No problem we are here to discuss it but Hallvard is right that we
would have 3 instances floating around now whereas 2 are enough if the
UFaceKit-SWT/... implementation is directly inheriting from EMF. We
can use advanced EMF-Features e.g. to effeciently restore booleans and
enums.

I'd say you should wait until I can show you a first ported version of
the SWT implementation backed by EObject instead of UBean/
UIControlBean - as stated from the outside view of an API user nothing
is going to change besides the 2 additional jars needed.

The additional jar-size is 1.2 MB as of now. I'm also going to discuss
with Ed how we could maybe split Ecore-Bundle in even more smaller
packages so the overhead should be as small as possible.

Tom

[Angelo zerr]

Hi Tom,

I don't know if you want use full EMF for Desktop or not.
Here the 2 solutions that I see :

Solution 1 : full EMF (for Desktop)

* SWT, Swing.. (Desktop) implementation will depends on EMF.
* GWT, .. (WEB...) implementation will not depends on EMF.

So

* AbstractUFaceKitEcore (Desktop) will extends EObjectImpl (EObject
implementation of EMF)
* ConstraintedDevice (WEB,...) will extends UbaseBean.

I'm not against having EMF dependecies, but perhaps Swing user will
not understood
why they must depends on EMF?

Solution 2 : EMF or not (for Desktop)

We can choose if we must based on EMF or not.
To do that, we must create 2 projects which defines
AbstractUFaceKitEcore with same package :

* org.ufacekit.ui.core.emf : we will have
org.ufacekit.ui.core.AbstractUFaceKitEcore which extends EObjectImpl.
* org.ufacekit.ui.core.ubean : we will have
org.ufacekit.ui.core.AbstractUFaceKitEcore which extends Ubasebean.

To choose if we want use EMF or not, we must just put the good jar
into classpath org.ufacekit.ui.core.emf.jar
or org.ufacekit.ui.core.ubean.jar.

For the 2 solutions, JFaceLabel code will have not dependencies with EMF.
We will have always this code :

public void set(int featureId, Object value) {
switch (featureId) {
case TEXT_PROPERTY:
setText(ConvertUtils.getString(value));
break;
default:
super.set(featureId, value);
break;
}
}

If it that, I don't understand the benefit of EMF?

Perhaps I 'm fully wrong, but I try to give solutions to understood
better your idea.

Angelo

[Tom]

I'll think about this thanks for your input - my intial thoughts went
along solution 1 but
I'll think about your idea too.

Tom

[Angelo zerr]

In fact I try to give examples to more understand your idea, but I
have not really thought about
the 2 solutions that I have explained.

Ok, your idea is full EMF. In this case, why not use EObject#eSet and
EObject#eGet
insead of using UBeanInterface#set and UBeanInterface#get into JLabel?

Perhaps the reason is to have commons Notification API (for GWT and SWT?)

2008/12/19, Tom <toms...@gmail.com>:

[Tom]

Hi,

Right all is uniform and if someone really really don't want to have
no EMF-Dependency SWT-Impl he/she is free to write one.
If we declare EObject to be our root-interface than you can't escape
EMF :-) Translating between UFaceKit-Events
EMF-Events is a piece of cake anyways.

Tom

On 19 Dez., 14:51, "Angelo zerr" <angelo.z...@gmail.com> wrote:
> In fact I try to give examples to more understand your idea, but I
> have not really thought about
> the 2 solutions that I have explained.
>
> Ok, your idea is full EMF. In this case, why not use EObject#eSet and
> EObject#eGet
> insead of using UBeanInterface#set and UBeanInterface#get into JLabel?
>
> Perhaps the reason is to have commons Notification API (for GWT and SWT?)
>

> 2008/12/19, Tom <tomson...@gmail.com>:

[Tom]

I've experimented a bit with this feature and delay the EMF-Base-
Implementation for now. Angelo you can restart working with the Code
base in Eclipse-Repo.

Tom