[
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
|
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
>