Hi,
The approach I've adopted when I was playing with this stuff two weeks
ago was to allow 2 types of serialization: one that is as clean as
possible (as any JSON user would expect) and another that has an
attribute to specify the Ecore metadata of the objects and an
attribute for proxy URIs. The latter type makes the loading step a
breeze but may offend some people.
Loading the former resource type involves a bit more work. Trying to
keep this "feature" as flexible as possible, I've defined a property
that can be used to specify the strategy to load such data: create
dynamic EClasses or try to match the serialized objects with EClasses
available in the registered packages. Obviously this analysis is
fairly expensive but yields the nice result of producing instances of
generated classes.
One problem with the code that I have now is that I've used a non-EPL
code to do the JSON serialization and deserialization. Would anyone
know a "blessed" code to do it? It would be fairly easy to switch this
"underlying" piece.
Best regards,
Marcelo Paternostro
IBM Toronto Lab
1-905-413-3942
marcelop@xxxxxxxxxx
Inactive hide details for Michael Scharf ---04/29/2008 10:27:33
AM---Ed,Michael Scharf ---04/29/2008 10:27:33 AM---Ed,
From:
Michael Scharf <Michael.Scharf@xxxxxxxxxxxxx>
To:
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
Date:
04/29/2008 10:27 AM
Subject:
Re: [eclipse-incubator-e4-dev] What I dislike about using EMF for e4...
------------------------------------------------------------------------
Ed,
I totally agree with you that JSON is missing two important
features of a data serialization format: Types and References/IDs.
I have cerated several JSON like formats that have types and
id/references. With those two extensions they are very good
data formats....
Michael
> 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
_______________________________________________
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
