[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipse-incubator-e4-dev] What I dislike about using EMF for e4...
|
Tom Schindl schrieb:
Mike Wilson schrieb:
Hm... I actually thought that it *was* possible to make it work like
"document.body.style.backgroundColor="#FF000";" but that was just
based on a brief conversation I had with someone who seemed to
understand Rhino better than me.
You are right it works and I've implemented it for our EMF-Workbench.
Ironically this gives me another reason why we need META-Model
information in our runtime or we have to represent all numbers we use
as DOUBLE-Values!!!!
See this piece of code:
public void put(String arg0, Scriptable arg1, Object arg2) {
EStructuralFeature f = findFeature(arg0);
// We always get a double so we have to convert to the
appropriate value
if( arg2 instanceof Number ) {
if( f.getEType().getInstanceClass() == int.class ) {
arg2 = ((Number)arg2).intValue();
}
}
if (f == null)
super.put(arg0, arg1, arg2);
else
eObject.eSet(f, arg2);
}
I've commited my changes to the repository. See
http://dev.eclipse.org/viewcvs/index.cgi/e4-incubator/ui/org.eclipse.e4.presentationmodel.pure.emf.workbench/src/org/eclipse/e4/presentationmodel/pure/emf/workbench/rhino/EMFScriptable.java?view=markup
We don't want our Domain-Object to implement this interface directly
because this is a rhino specific thing and other scripting
technologies may use different strategies, and because we wrap it the
Wrapper needs to translate this into our real model implementation.
I guess what I was getting at though was that when I'm looking at one
of the model objects it should look like it's as simple as the
equivalent JSON object, and it probably doesn't need a lot more than
that in the way of capabilities.
If JSON is the interface we want to match this is IMHO a bad decision.
It always boils down to the fact that by concentrating so much on
Scripting-Community that we forget about there are still a lot of
people who want to interface with our model using plain old java and
JSON is nothing more than a little bit more than HashMapWrapper. In my
last project I did AJAX and it's like hell if your model get's a bit
more complex.
I think this is a good point. JSON should not be the interface to match.
I have had similar experiences with a lage AJAX project I worked on that
already used JSON for almost any data model. For an external developer
this was a huge pain. It is the same problem you encounter with hash
maps. You never really know which keys a map supports, which data types
the values of these keys can have. If you have references you have to
kepp them in sync manually, etc. One of the first things we did was to
wrap the JSON data with accessor classes with setter and getter methods
for each key. This means some performance overhead but it greatly
improves the maintainability of the program.
In my opinion JSON is great for sending structured data to AJAX
applications but that is about it. I should be considered simply as
another serialization format.
Best Fabian
--
Fabian Jakobs
JavaScript Framework Developer
1&1 Internet AG
Brauerstraße 48
76135 Karlsruhe
Amtsgericht Montabaur HRB 6484
Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren