[
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...
|
well I guess JSON was invented to be light weight and as the standard
serialization format for JavaScript. There's standard XML-Parser
available in JavaScript (if you don't want to use an ActiveX-Komponent
in IE).
So instead of working on an XML-DOM JavaScript guys can work on
JavaScripts Object-class level. The Object-class in JavaScript can be
compared with an HashMap in Java.
JavaScript:
-----------
var myObject = new Object();
myObject["key_1"] = "val";
myObject["key_2"] = 10.5;
Java:
-----
HashMap myObject = new HashMap();
myObject.put("key_1","val");
myObject.put("key_2",new Double(10.5));
As far as I remember JavaScript Engines can deal with constructs like
this out of the box:
var myObject = { "key_1": "val", "key_2": 10.5 };
This allows JavaScript developers to request an object from the server
and let the scripting engine parse it for them into a DOM. If you don't
translate this in real world objects it would be the same as we would
work on XML-DOM in our Java applications.
Tom
Ed Merks schrieb:
Fabian,
Thanks for sharing your experience. Marcelo Paternostro was
demonstrating his EMF JSON serializer to me the other day; I guess this
might be a useful thing in the e4 incubator? I'm not sure I fully
understand the use case for JSON yet though. JSON does strike me as
pretty much useful only as a serialization format and even then, the
limitations compared to XML are kind of glaring. The lack of metadata is
an obvious one. As you read the data, there's really no indication of
what types of complex objects need to be created, so barring some
additional information, you end up with maps of lists/array with some
strings and numbers for the leaves. Even even at this simple level,
there's no support for non-containment references, i.e., sharing of
complex objects within the tree structure. Of course we can work around
this by storing a "type" property in each object and by using strings
that act as references just href does in HTML. But as you say, JSON is
another one of these low bars that would be difficult to limbo
underneath though exceedingly easy step over toward a higher goal.
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
Inactive hide details for Fabian Jakobs <fabian.jakobs@xxxxxxxx>Fabian
Jakobs <fabian.jakobs@xxxxxxxx>
*Fabian Jakobs <fabian.jakobs@xxxxxxxx>*
Sent by:
eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
04/29/2008 02:50 AM
Please respond to
E4 developer list
<eclipse-incubator-e4-dev@xxxxxxxxxxx>
To
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc
Subject
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
_______________________________________________
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
--
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