Re: [eclipse-incubator-e4-dev] Initial discussion on the 'modelled' work

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

>>I think
the contrary is the case.  A weakly typed with almost no metadata
>>leaves the user with code that's right only if it behaves right
after
>>extensive testing. 

Just to get ahead of things, I'd like
to avoid discussions that reduce down to the merits of a static typing
vs. weak typing vs....  Not that I thought you were doing this Ed,
just making a blanket statement early in.  You know, there's more
than a few former Smalltalk programmers here (sniff) and I'd love to live
in a world where our Java doesn't require extensive testing.  At this
point, everyone's picked sides, the arguments have been played out, and
beliefs border on the religious without much chance of converting someone.

I'm completely with you in the value
of first class metadata support.

What's clear is that we'll need to drive
the model from languages which run the gammut of typing.  Your response
below Ed suggests that EMF is flexible in this regard, right?  But
is that just in the definition of the model or in consumption too?  How
do we say access a strongly typed EMF model from a language like _javascript_?

Kevin

Ed Merks/Toronto/IBM@IBMCA
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

04/06/2008 04:04 PM

Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>

To	E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc	"E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>, eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
Subject	Re: [eclipse-incubator-e4-dev] Initial        discussion        onthe'modelled'workbench UI

Comment below.


Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265  (t/l 313)



eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx wrote on 04/06/2008 01:35:15
PM:

>
> Tom, have no fear..I'm not at all closed on discussions about the
> API. I was just going to start them -independently- of whether or
> not EMF is a suitable candidate as 'Model Server' (we should likely
> start a different thread for this)...the question remains; can EMF
> emulate the current API and, if so, at what cost?

Another important question, which I think Tom is raising, seems to be:
what's the basis for the current API?  Why is it the way it is? Why
is it
the benchmark?  I can see it's very minimal, but the design motivations
aren't so clear.

>
> Your comment "Eric's model is perfectly suited for scripting
guys"
> is true.

I think the same is true for EMF.  In fact, I think it's even more
true...

> Given that this is a design requirement I don't think that
> it's inappropriate. I realize that there's a trade-off between an
> unbounded and untyped 'bag of properties' and a formalized full on
> completely meta-modeled structure. The main problem I see with the
> fully modeled approach is that I fear that it'll make our users life
> more difficult.

I think the contrary is the case.  A weakly typed with almost no metadata
leaves the user with code that's right only if it behaves right after
extensive testing.  What aspect of full modeling do you think will
make the
user's life more difficult?  Something like DOM is very flexible yet
most
folks don't consider DOM to be a good API for general purpose data
manipulation...

> If they want to use ModelElement as the basis for -
> their- domain object will they be required to get into writing an
> ECore extension to the ETreeModel metamodel (or whatever the EMF
> equivalent is) n order to use the JFace viewer ?

EObject is just like ModelElement, only richer in that it is strongly
typed.  And don't confuse strong typing with static verse dynamic
typing.
EMF supports all these things.  It's often the case that any model
can be
rendered in a variety of different ways, so I'm a bit curious about the
fact that you seem to be implying that there is kind of a direct one-to-one
correspondence between model and view...

> I'd be more than
> glad to find out that this is YAGF (Yet Another Groundless Fear...;-).

Anyone can define a model independant of all other models, and the model's
API need not reveal it's basis in EMF in the API.  I.e., there's no
need to
extend EObject in the interfaces.  So users just design a model using
annotated Java, XML Schema, Ecore, UML, or anything else folks might dream
up as a nice way of describing a model.  Similarly I would imagine
it
should not be necessary to see ModelElement in any client-defined API;
it
would just be an implementation detail.

>
> The 'loose' approach is based on a concept of 'common properties';
-
> any- ModelElement that contains a GUI_LABEL and/or a GUI_IMAGE
> property can be hosted in a tree (or a menu, toolbar or CTabItem)
> making it very simple for clients to use for -their- work.

EMF is able to show a default tree view for any model already.  The
more I
read, the more I get the impression that ModelElement is almost like a
view
element.  I don't imagine that folks would generally want to "pollute"
their data model with information about how it's viewed/rendered in any
one
particular viewing/rendering technology...

>
> My bet is that we're going to end up in the middle somewhere,
> completely untyped/bounded is -too- loose. Perhaps one approach is
> to provide meta-information on a 'per property' basis (i.e. a
> property would have to be 'registered' (including meta info) against
> a 'type' before it can be set in that type.

Wouldn't it be good to fully understand EMF before placing bets?  Are
you
so sure it doesn't provide everything you need already without being overly
restrictive?

> I was expecting to do
> this using an 'exemplar' model; you'd 'register' a ModelElement
> whose current structure (its properties and their data types)
> represent the valid properties (and their defaults?) but API might
> be ok as well (I'm not really anti-api, I just think if should be
> generated from the model...;-).

So if someone make a mistake in their instance, it would become explary?
 I
consider API and model to be effectively equivalent because, given a model,
I can generate an API, and given that API, I can reconstruct the model.
Besides, being anti-API seems like being against motherhood.  It's
the
basis for all things.  You know that XML Schema has things like wildcards
to deal wtih open content; there are all kinds of good comprimises between
being suitably well constrained to find errors quickly and early as well
as
being suitably flexible to accomodate the unexpected later on.  I
get the
feeling that a lot of useful knowledge that would come from looking clostly
at XML Schema, UML, and Ecore is simply being overlooked.  Even if
there is
a good reason for doing that, nevertheless, if you don't learn from the
mistakes of others, your most likely doomed to repeat them...

>
> This remains a primary concern of mine; the end result must be
> easily consumable downstream, both to understand and to extend.

This is the central mantra behind the model driven development vision.


>  I
> found it interesting when initially looking at JSON that it's rate
> of acceptance is high because it's -simpler- than other
> infrastructures that it was competing against..perhaps they're onto
something.

As I undertand JSON, it's a reflection of JavaScipts type system.  If
this
was really such a great thing, we'd all have switched to JavaScipt because
it's so simple and flexible, unlike Java, which is complex and rigid.
Designs decisions are such that the things at the extremes are usually
optimal...

>
> One thing that nobody's mentioned yet are the CSS requirements; if
> we get this right (and we must) then almost all of the 'properties'
> we're talking about modeling here (tab style, min/max buttons,
> colors/fonts...perhaps even the SWT widget to render with) will be
> coming from the styler and won't even -be- a part of the ModelElement's
data.

Ofthen in modeling there are patterns you might think of as decorator
patterns.  This seems like one of them.  You have an underlying
model that
can be decorated to render it in different ways.  Things like adapters
an
item providers, which interact with content providers serve this type of
role as well.  This outline by Jim van Dam seems related to this styling
issue.

(See attached file: StUIML Management Summary.pdf)

>
> Whatever we end up using (both as API and as implementation) the
> only two things that someone's going to have to use a big stick to
> beat me off of are:
>
> 1) -All- GUI changes take place as responses to an observable model.
> Otherwise it's not MVC

This was one of the central design goals of EMF.  Notifications must
produce enough information that you can use them to update your views.
Consider that EMF's change model provide a change recorder that lets you
record all changes you make to a model, cover it to a change description,
which you can them apply to undo and redo all the changes.  The change
description itself is a model, so you could sent it somewhere else
(serialize it) and apply the same changes to a different copy of the
objects...

>
> 2) The protocol currently enforced in the ControlFactory's
> 'createGUI' and 'disposeGUI' methods be the -only- path through with
> rendering elements are managed.

Not sure I understand this one.  Model instances definitely are created
by
a factory.  Viewing is typically done by using adapters that interact
with
content/label providers.  Those adapters can indeed be disposed when
the
view is disposed...


>  This is needed to enforce the CSS
> styling (as well as a way to maintain sanity in the world...;-).
> Tom, the reason that the 'clientArea' gets added to the 'contents'
> as well as being its own property is to get the rendering for take
> place in the ControlFactory's 'processContents' part of the protocol).

I think Tom will understand this better than I.  I kind of always
imagine
models being focused just on the data they represent and that views act
as
decorators around such things.  It's of course highly likely that
we're
using the world model to mean slightly different things.  I'm sure
when we
meet in the middle, we'll both be like: ah, I see now what you meant. ;-)


>
> time for lunch,
> Eric
>
>

> On Sat, Apr 5, 2008 at 11:09 AM, Boris Bokowski
<Boris_Bokowski@xxxxxxxxxx
> > wrote:
> Kevin wrote:
> > At the risk of killing momentum, I'd like to suggest that this
> > investigation would work best if someone on the platform team
(yes,
> > I'm looking at you Eric <g>) were involved to whatever
degree it
> > made sense.

> I am a little surprised - Kevin did you realize that Tom is *already*
a
> member of the Platform team, as a Platform UI committer?
>
> Yes, Eric should be involved in this, but I also think that Tom should
be
> allowed to do the same thing Eric has done - produce some experimental
code
> to be used in the discussion (code speaks!) - and I have therefore
> nominated Tom as an e4 committer.
>
> For higher-bandwidth communication, we can use the #eclipse-dev channel
> (see http://wiki.eclipse.org/IRC). I know that both Eric and Tom can
be
> found there regularly. Please remember to post occasional updates
to the
> mailing list as well...
>
> Boris
>
> _______________________________________________
> 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

Attachment: StUIML Management Summary.pdf
Description: Binary data