DWR vs JSON

View: New views
3 Messages — Rating Filter:   Alert me  

DWR vs JSON

by Chris Bowling :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Some parts of this message have been removed. Learn more about Nabble's security policy.

Joe and anyone with feedback,

 

This is less of a technical problem than it is a design question.  The basic scenario is we have been using DWR successfully for several projects.  We are in the design stages of our most recent project and the front-end is really pushing for a dojo/JSON solution instead of DWR.  Basically they want to send a request to a url with some params, have us direct the url to our SpringMVC controller, call our spring beans to do the business tasks, then in the controller basically do a response.getOutputStream.write(), writing out a converted object in JSON format. 

 

Besides not wanting to write all the additional implementation, JSON conversions, and basically doing what DWR does for us, this solution just doesn’t seem sound.  The big concerns coming from the front-end is that DWR doesn’t return JSON objects which means if they were to use Flex or some other technologies it wouldn’t be compatible.   After giving my reasons why DWR is the best solution to our group I was wondering if anyone could give additional feedback to: 1) Explain why DWR is the best technical solution, that is what does it give us that other solutions don’t 2)Why the proposed use of JSON and writing it out in the response is not a technically sound solution when compared to DWR.

 

Any feedback and input is greatly appreciated since this discussion will most likely lead to how our future projects are implemented.

 


Parent Message unknown FW: DWR vs JSON

by Chris Bowling :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Posting this email trail in response to my original post for any others
looking for similar information.


-----Original Message-----
From: Chris Holland [mailto:frenchy@...]
Sent: Friday, June 22, 2007 2:03 PM
To: Chris Bowling
Subject: Re: [dwr-dev] DWR vs JSON

Cool, good luck :)

-chris

On 6/22/07, Chris Bowling <Chris.Bowling@...> wrote:
> Thanks Chris
>
> Yeah the sample code was just some sample pulled from an
implementation
> on how the front-end team was going to make the calls.  The actual
code
> is meaningless.  Thank you for your points though.  Having used dwr
> extensively I totally agree with what you've said and I think by
seeing
> that others are saying the same thing will help the team in its
> decision. And you pointed out a few things like payload size that I
> hadn't thought of.
>
> The other point I had is that both me and the front-end devs who will
be
> implementing the integration are familiar and comfortable with DWR, so
I
> can't see any reason why not to continue to use it(especially given
joes
> last email about the JSON support for those cases where it is needed).
>
> Anyways if you have any other thoughts or input please feel free to
pass

> them on.
>
> Thanks again,
> Chris
>
>
> -----Original Message-----
> From: Chris Holland [mailto:frenchy@...]
> Sent: Friday, June 22, 2007 1:38 PM
> To: Chris Bowling; Joe Walker
> Subject: Re: [dwr-dev] DWR vs JSON
>
> Aaah, interesting!
>
> re 1) What would populateDiv do?
>
> re 2), I would be weary of building an ad-hoc JSON interface to your
> business logic. Keeping in mind that anything returned as a valid
> javascript string can be loaded, and read by any malicious web
> document on the Internet, and you obviously want heavy checks and
> balances around that. See a couple of Joe's articles on the subject:
>
>
http://getahead.org/blog/joe/2007/04/04/how_to_protect_a_json_or_javascr

> ipt_service.html
>
> Joe's baked all that stuff right into DWR, which has been thoroughly
> poked at, and apparently received high marks on security by some
> experts. It really depends on the nature of the data you're dealing
> with. Security may not be a concern. But if you're loading someone's
> address book over JSON, then you may have issues. In your developers'
> shoes, I'd rather not put myself thru the lack of sleep or the added
> thinking if I can avoid it.
>
> You might further insist by your developers, that DWR is a generic
> "one-click" way of exposing any method as a service elegantly
> accessibly to JavaScript. You don't have to think about converting
> Java Objects to JSON, all that's done behind-the-scenes, and in a more
> efficient way, because i bet that comparing a pure JSON payload vs
> DWR's optimized payload, results in smaller output. JSON becomes
> especially overkill/verbose when you return a large array of identical
> objects with the same fields. Think about it, you're repeating each
> field's name with each object in the array.
>
> I like JSON as lighter-way to do data *interchange* between different
> run-time environments, say from javascript-land to python-land to
> php-land, without clobbering ourselves up with big ol' XML markup
> overhead.
>
> While DWR might look scary from the outset, the "Get Started" guide
> gets you there in no time: http://getahead.org/dwr/getstarted
>
> -chris
>
>
> On 6/22/07, Chris Bowling <Chris.Bowling@...> wrote:
> > Hello Chris,
> >
> > Thank you for your reply.  I will check out the library you
mentioned.
> > To your other points.  The first is a great point and something that
I
> > have been saying myself.  That is, both objects eval to the exact
same
> > thing and from what I've seen there is no difference at that point
in
> > how they can be used.  Thank you for confirming that.  And to your
> > second point dojo and DWR are definitely not incompatible as I have
> > provided solutions of how to implement such a solution.
> >
> > That being said it seems the main hold up is really that;
> >
> > 1)the front-end is pushing to just define urls to send the requests
to

> > since that is how they are used to making ajax requests and it
> decuples
> > the front-end from the back completely.  Dojo just happens to be the
> > means in which they will do that.  Example:
> >
> > function getBookInfo(bookId) {
> >  var params = new Array();
> >  params['bookId'] = bookId;
> >  var bindArgs = {
> >   url: "book.jsp",
> >   error: function(type, data, evt){
> >           alert("error");
> >          },
> >   mimetype: "text/json",
> >   content: params
> >  };
> >  var req = dojo.io.bind(bindArgs);
> >  dojo.event.connect(req, "load", this, "populateDiv");
> > }
> >
> > 2)if it's possible to implement the solution without DWR with a
simple

> a
> > response.getOutputStream.write(), writing out a converted object in
> JSON
> > format, why should they bother using DWR
> >
> >
> > Thanks again for your feedback.  Like I said this is actually a very
> > important discussion here to decide which ajax solution is perfered
> for
> > all projects going forward, so any input from others confirming or
> > adding to the information we already have is greatly appreciated.
> >
> > -Chris
> >
> >
> >
> > -----Original Message-----
> > From: Chris Holland [mailto:frenchy@...]
> > Sent: Friday, June 22, 2007 12:54 PM
> > To: Chris Bowling; Joe Walker
> > Subject: Re: [dwr-dev] DWR vs JSON
> >
> > Hi Chris :)
> >
> > I wanted to reply to you in private in case I'm slightly off-topic.
> >
> > I've never developed an app with flex, but if your developers'
> > concerns revolve around being able to have agility around
"injecting"
> > the data they get back from the server into an HTML document, then a
> > lightweight, narrowly-focused library i recently built to
specifically
> > address this might be of interest to them:
> >
> > http://ibdom.sourceforge.net/project_site/ibdom_and_dwr/
> >
> > But to get back to your developers' concerns about DWR vs JSON, i'm
a
> > bit confused.
> >
> > JSON is simply one of many possible string representations which,
when
> > "eval'ed" in a JavaScript environment, results in the generation of
> > JavaScript Objects.
> >
> > While what comes out of DWR may not be exactly JSON, in the end, it
> > still ends-up sending JavaScript Objects and Arrays of JavaScript
> > Objects back to the client. From what i could sniff out, DWR sends
> > optimized JavaScript output resulting in the "smallest possible way
to
> > generate your collection of objects". Whether that string output is
in
> > JSON format or not, shouldn't matter to a JavaScript Engine, in the
> > end, it should "eval" to the exact same objects.
> >
> > While i have little experience with Dojo, its processing of JSON
> > output must simply mean that it knows how to process JavaScript
> > Objects, to provide convenient means to manipulate and inject data.
> > Dojo may very-well NOT be incompatible with DWR.
> >
> > Let me know if i'm completely off-base :) Looking forward to see
what

> > you guys are building though :)
> >
> > -chris
> >
> >
> >
> > On 6/22/07, Chris Bowling <Chris.Bowling@...> wrote:
> > >
> > >
> > >
> > >
> > > Joe and anyone with feedback,
> > >
> > >
> > >
> > > This is less of a technical problem than it is a design question.
> The
> > basic
> > > scenario is we have been using DWR successfully for several
> projects.
> > We
> > > are in the design stages of our most recent project and the
> front-end
> > is
> > > really pushing for a dojo/JSON solution instead of DWR.  Basically
> > they want
> > > to send a request to a url with some params, have us direct the
url

> to
> > our
> > > SpringMVC controller, call our spring beans to do the business
> tasks,
> > then
> > > in the controller basically do a response.getOutputStream.write(),
> > writing
> > > out a converted object in JSON format.
> > >
> > >
> > >
> > > Besides not wanting to write all the additional implementation,
JSON
> > > conversions, and basically doing what DWR does for us, this
solution
> > just
> > > doesn't seem sound.  The big concerns coming from the front-end is
> > that DWR
> > > doesn't return JSON objects which means if they were to use Flex
or

> > some
> > > other technologies it wouldn't be compatible.   After giving my
> > reasons why
> > > DWR is the best solution to our group I was wondering if anyone
> could
> > give
> > > additional feedback to: 1) Explain why DWR is the best technical
> > solution,
> > > that is what does it give us that other solutions don't 2)Why the
> > proposed
> > > use of JSON and writing it out in the response is not a
technically
> > sound
> > > solution when compared to DWR.
> > >
> > >
> > >
> > > Any feedback and input is greatly appreciated since this
discussion

> > will
> > > most likely lead to how our future projects are implemented.
> > >
> > >
> >
> >
> > --
> > Chris Holland
> > http://chrisholland.blogspot.com/
> > http://ibbydev.blogspot.com/
> >
> >
> >
>
>
> --
> Chris Holland
> http://chrisholland.blogspot.com/
> http://ibbydev.blogspot.com/
>
>
>


--
Chris Holland
http://chrisholland.blogspot.com/
http://ibbydev.blogspot.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


Parent Message unknown FW: DWR vs JSON

by Chris Bowling :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Posting this email response to my original post for any others looking
for similar information.


-----Original Message-----
From: Joe Walker [mailto:joe@...]
Sent: Friday, June 22, 2007 1:28 PM
To: Chris Holland
Cc: Chris Bowling
Subject: Re: [dwr-dev] DWR vs JSON


Just quickly: 2 points.

The reason why we have not released JSON support is that we can't
support a number of DWR features when using JSON:
- batching
- pre/post hooks
- recursive data structures
- XML DOM transfers
- CSRF security protection
- there are others I'm sure

However - I understand that JSON is a good idea from an interop POV, so
I've been adding it into DWR, and it should be there in version 2.1
DWR as it stands is very close to supporting JSON, there are just a few
tweaks left, so if you can help test I'm sure we can have a release
fairly soon with it in.

Joe.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

LightInTheBox - Buy quality products at wholesale price