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
--
Chris Holland
http://chrisholland.blogspot.com/http://ibbydev.blogspot.com/---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@...
For additional commands, e-mail:
dev-help@...