[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [eclipse-incubator-e4-dev] Initial discussion on the 'modelled' workbench UI
|
Yves,
One thing you could do is use your tool to help us reverse engineer the
prototype API into an Ecore model...
Cheers,
Kenn Hussey
Program Manager, EA/Studio
[Embarcadero Technologies Logo]
Embarcadero Technologies, Inc. | www.embarcadero.com
110 Spadina Avenue, Suite 400 | Toronto, ON M5V 2K4
Kenn.Hussey@xxxxxxxxxxxxxxx
Mobile: 613-301-9105
-----Original Message-----
From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
[mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of
yves.yang@xxxxxxxxxxx
Sent: Friday, April 04, 2008 10:06 AM
To: E4 developer list
Cc: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
Subject: Re: [eclipse-incubator-e4-dev] Initial discussion on the
'modelled' workbench UI
Hi all,
I'm very interested in this tropic since I work on a project VEX
(subproject of VE for XML GUI), which definitively needs an UI model.
The
current implementation VEX for our customer relies on EMF model. Please
let me know what I can do for this issue.
Best regards
Yves YANG
> Tom,
>
> I personally like EObject being in the API for exactly this type of
> reason.
> I.e. it provides a very small set of extremely useful methods to
access
> the
> adapters (for receiving notifications), the container, the contained
> children, the metadata, and so on as well as making it easy to apply
any
> reflection-based utilities to the instance. But some folks are
purists
> and
> don't want any method other than the ones they've provided visible.
(Those
> same people aren't the least bit bothered by all the methods that
> java.lang.Object introduces into their class hierarchy.) Other folks
are
> pseudo purists and want to define their own facade API instead. For
these
> reasons, I try to make EMF be more like plastic, so that it can be
molded
> to best suit other people's ideals rather than just my own...
>
>
> Ed Merks/Toronto/IBM@IBMCA
> mailto: merks@xxxxxxxxxx
> 905-413-3265 (t/l 313)
>
>
>
>
>
> Tom Schindl
> <tom.schindl@best
> solution.at>
To
> Sent by: E4 developer list
> eclipse-incubator
<eclipse-incubator-e4-dev@eclipse.o
> -e4-dev-bounces@e rg>
> clipse.org
cc
>
>
Subject
> 04/04/2008 08:08 Re: [eclipse-incubator-e4-dev]
> AM Initial discussion on the
> 'modelled' workbench UI
>
> Please respond to
> E4 developer list
> <eclipse-incubato
> r-e4-dev@eclipse.
> org>
>
>
>
>
>
>
> Ed Merks schrieb:
>> Kevin,
>>
>> Comments below.
>>
>>
>> Ed Merks/Toronto/IBM@IBMCA
>> mailto: merks@xxxxxxxxxx
>> 905-413-3265 (t/l 313)
>>
>>
>>
>> eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx wrote on 04/03/2008
>> 06:40:36
>> PM:
>>
>>> I believe there's going to be a lot of reluctance to introducing EMF
>>> into the platform.
>>
>> Really, I wonder why you believe that? So far there seems to be
mostly
>> support in favor of reusing long established technology and
experience.
>>
>>> Although maybe not for good reason.
>>
>> I suppose we can dismiss the bad reasons pretty quickly and then
focus
>> on
>> the good reason.
>>
>>> The problem
>>> with these kinds of discussions is that they're so abstract that its
>>> easy for personal preferences or ignorance (in this case, mine) to
>>> get in the way.
>>
>> Yes, human nature will always be what it is. Just as the neighbour's
> grass
>> always looks greener, your own baby always seems cuter. (I've
figured
> the
>> greener grass thing out though. It's because grass from an angle
looks
>> greener than if you look straight down at it. So the neighbours
grass
>> looking greener is perspective thing than changes as soon as you walk
> over
>> and look closely to notice the bare earth and the infiltrating
weeds.)
>>
>>
>>> I've not done any in-depth EMF work, I'd say I've
>>> more been acquainted with an EMF model or two but, well you know,
>>> never really gotten to know them. I'm sure their really wonderful
>>> once you take the time, I'm embarrased to say that I've not.
>>
>> Given that you can completely suppress EMF (EObject, EList, and so
on)
> from
>> the model's API, you might even have met a few "closet" EMF models.
:-P
>>
>
> Well there are things we can't hide from the API because we need a
> possibility to attach-listeners to our model so what we need to expose
> are the things coming from EMF-Common (Adapter, Notification) if I'm
not
> completely mistaken.
>
> I'm going to study Eric's code on the weekend to understand how his
> model works :-)
>
> Tom
>
> --
> B e s t S o l u t i o n . a t EDV Systemhaus
GmbH
>
------------------------------------------------------------------------
> tom schindl leiter
softwareentwicklung/CSO
>
------------------------------------------------------------------------
> eduard-bodem-gasse 8/3 A-6020 innsbruck phone ++43 512
935834
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
>
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev