[
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...
|
>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
