Re: [eclipse-incubator-e4-dev] YAMI (Yet Another Model Interface)

[Michael Scharf <Michael.Scharf@xxxxxxxxxxxxx>]

Eric Moffatt wrote:
> Michael, when you say...
>
> "It is similar to IObservableModel [3] but it seems to be more complete"
>
> I can't help but think of Mike M's comments about simplicity trumping 
> capability in the AJAX community (I guess I'm a closet AJAX guy...;-). 
> We're going to have to 'sell' what we come up with to the community at 
> large or we fail. At best this is going to mean successfully conveying a 
> substantial paradigm shift (to modeling). IMO, anything showing up 
> that's not currently needed will just make the story harder to sell...

JSON is good -- but assuming you have no model when you use JSON is
wrong. There is a model in the mind of the developers. The new TCF
project uses JSON as default data exchange format. BUT there is a
prosa document describing the JSON data. So, instead of having a
formal model an "mental" model is used that both sides somehow
implicitly know. I prefer models that are available in the code.


Just this afternoon I filed a bug against RSE because there is no
model describing the data that is shown in a table:
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=229944
RSE has a tabel that can show arbitrary data. The abstraction
does not require to provide the table with a model (meta information
about the types of data). Instead, a IPropertyDescriptor describes
each cell in the table. IPropertyDescriptor does not provide you the
type of the property (it is not part of the protocol).

The table makes the assumption that each row in the table describes
objects of the same type. To determine the column headers, it
takes the first row in the table and looks at each of the attributes.
It also tries to infer the type of the column by looking at the
value. If the value happens to be null, then it makes (currently)
the assumption it is a string. But if it happens to be a int then
sorting and formatting of the column gets wrong....

If there would be some meta-model facilities in the core of eclipse,
then those could have been used. It seems the designers of this
table did not feel like inventing their own meta-model and therefore
they used the closest abstraction they could get from the platform:
IPropertyDescriptor.



> Of course that's not to say that having the capabilities is bad just 
> that we should only expose what's necessary to handle the work-flows we 
> expect in e4's -first- release...
>
> Each part of  API 1.0 should have a clear and current -need- to be 
> there, backed by a work-flow that documents its necessity ('we might 
> need this' is not a work-flow...;-).

For example: If we would have a common meta-model, then it would be
possible to have tables that are based on the meta model. This would
give the user sorting and potentially filtering for free. I wonder
how many "generic" tables and "generic table filters" and "generic
sorters" are hosted at eclipse....

I am giving the table example, because about 10 years ago we restructured
an IDE called SNiFF written in C++ based on Erich Gammas and Andre Weinand
ET++ framework. This IDE had lots of different data shown in all kinds of
trees and table. ET++ had something similar to item and label providers.
But things like sorting, filtering, column selection had to be written
by hand for each table. This lead to lot of duplicated code and lots
of inconsistencies. Like in eclipse today. Some tables allow sorting,
some don't. Some have filters, but each table has it's own style
filter dialog. Some table allow you to select the colums to display,
but there is no common way of doing this.

Then we introduced a strong and capable meta-model that was able to describe
tabular (and tree) data. On top of that metamodel we were able to write
common facilities which not only reduced the code and the cost of
creating a new table/tree view, it also created a more uniform
look and feel.

Another example are query builders or search and filter expression.
Each application in eclipse uses its own mechanism. To be able
to create a query you need a metamodel that describes the underlying
model. Let's take the simple case where we just want to model the
WHERE clause of a SQL or OQL expression. There are right now
many solutions eclipse doing this. Just a few examples:
- RSE has primitive filters
- Mylin has a UI to do queries on bugzilla repositories
- the Problems view "Configure content" is a restricted filter
- rssowl has a thunderbird like query language
- jazz has a really cool query builder
- the data tooling has a query builder
- the eclipse memeory analyzer has a UI to build OQL queries
...

The platform could provide some metamodel and some default
query builders based on a metamodel. The query builder would
create an AST for the expressions. There could be a simple
expression evaluator interpreter that could be used for
small tables, but users could use the AST and translate it
into the say an SQL query...

What is required for this functionality is a metamodel
that can be used to describe the data structures and
some way to get the data out of the objects....

Sure, one could have one metamodel for filters, another
one for tables, another one for dialogs, another one
for...

> Form follows function; Instead of asking 'What does it look like?' maybe 
> we should be asking 'What do we need and why'. As long as the resulting 
> API (including every argument of every method) is not only capable of 
> but -necessary to- supporting these requirements everything else is 
> semantics, necessary but relatively unimportant.

100% agreement!

> As we proceed it'll surely grow but that growth will be driven by an 
> identified need (as it is currently in our current API's).

yes...


Michael