RE: [eclipse-incubator-e4-dev] What I dislike about using EMF for e4...

[Ed Merks <merks@xxxxxxxxxx>]

Mike,

As far as I understand it, which might be even less than you :-P JSON is just one of the ways that data is transferred when using AJAX; the X stands for XML. For very simple data, where the meta data might well be implicit or irrelevant, it likely represents a very good way, especially compared to the full complexity of what an XML processor needs to support. But as a format for long term persistence of complex data, it seems to fall far short on necessary features. I've certainly not seen an industry trend to drop XML in favor of simpler JSON. As always, simple problems can be easily solved with simple solutions while complex problems often require more.

I'm not exactly sure how we went from discussing APIs to a completely orthogonal concern like persistence/exchange formats. Aren't these discussions fun!


Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)


"Mike Milinkovich" <mike.milinkovich@xxxxxxxxxxx>

"Mike Milinkovich" <mike.milinkovich@xxxxxxxxxxx>
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

04/30/2008 04:50 PM

Please respond to
mike.milinkovich@xxxxxxxxxxx; 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...

>From what I've seen[1], JSON is the de facto standard in the Ajax world. No
matter what features it is lacking, that's what people are using. I doubt
we're going to change their minds :-)

Basically, my observation is that in the Ajax world lightweight and simple
pretty much always trumps completeness and fancy features. 

[1] Obviously, my technical credentials are suspect at best :-) By "I've
seen" I mean what I've observed from being on the board of the OpenAjax
Alliance for the past 1.5 years and monitoring the IDE, Runtime and Hub
lists there. 

Mike Milinkovich
Office: +1.613.224.9461 x228
Mobile: +1.613.220.3223
mike.milinkovich@xxxxxxxxxxx

> -----Original Message-----
> From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx [mailto:eclipse-
> incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Michael Scharf
> Sent: Tuesday, April 29, 2008 10:27 AM
> To: E4 developer list
> 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/or
> g/eclipse/e4/presentationmodel/pure/emf/workbench/rhino/EMFScriptable.j
> ava?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