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/[EMAIL PROTECTED]
mailto: [EMAIL PROTECTED]
905-413-3265 (t/l 313)
Fabian Jakobs
<[EMAIL PROTECTED]
nd1.de> To
Sent by: E4 developer list
eclipse-incubator <[EMAIL PROTECTED]
[EMAIL PROTECTED] rg>
clipse.org cc
Subject
04/29/2008 02:50 Re: [eclipse-incubator-e4-dev] What
AM I dislike about
using EMF for e4...
Please respond to
E4 developer list
<eclipse-incubato
[EMAIL PROTECTED]
org>
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
<<inline: graycol.gif>>
<<inline: pic16903.gif>>
<<inline: ecblank.gif>>
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
