>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 [EMAIL PROTECTED] > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:eclipse- > [EMAIL PROTECTED] 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/[EMAIL PROTECTED] > > mailto: [EMAIL PROTECTED] > > 905-413-3265 (t/l 313) > > > > > > Inactive hide details for Fabian Jakobs > <[EMAIL PROTECTED]>Fabian > > Jakobs <[EMAIL PROTECTED]> > > > > > > *Fabian Jakobs <[EMAIL PROTECTED]>* > > Sent by: > > [EMAIL PROTECTED] > > > > 04/29/2008 02:50 AM > > Please respond to > > E4 developer list > > <[email protected]> > > > > > > > > To > > > > E4 developer list <[email protected]> > > > > 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 > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev > > > > > > --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > eclipse-incubator-e4-dev mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev > > _______________________________________________ > eclipse-incubator-e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
