Skip to main content
[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

Back to the top