[Dojo-interest] Marshalling support
hfuecks at gmail.com
Tue May 24 08:40:52 PDT 2005
On 5/20/05, David Schontzler <schontz at gmail.com> wrote:
> On 5/20/05, Jason Carreira <jcarreira at gmail.com> wrote:
> > I haven't looked that much at the back button stuff, but here's a scenario
> > that I just thought of...
> > Let's say I'm showing a catalog that someone is shopping in, and
> > asynchronously updating their shopping cart when they add items, sending an
> > XHR message to the server and having it update the shopping cart display.
> > Now let's say the user wants one more item, adds it to the cart, and quickly
> > clicks the checkout button... which one gets through first, the shopping
> > cart add or the checkout? What if my policy is that things like checkout are
> > synchronous full-page requests to the server?
> > These edge cases are the kinds of issues that are going to bite people, and
> > Dojo should have good answers out of the box.
> Off the top of my head, I'd suggest that bind() allows you to get at
> all "unfilled requests", so then when someone clicks checkout the
> request info could be bundled up and passed along OR the checkout
> could wait for the requests to complete. We should definitely have
> some way to monitor pending requests.
As mentioned, my take on this is providing each request a sequence
number then "buffering" callbacks until previous requests have
completed or timed out. Seems to be the easiest way to implement it in
a manner which removes the need for Dojo users to think about.
The shopping cart example leads to another interesting problem area,
that of handling recordsets in general via XMLHttpRequest.
There's an interesting project called XULRecordset
(http://xulrecordset.sourceforge.net/) which uses JPSpan plus XUL and
XBL to allow users to add "recordset" tags to their UI, which I think
it a great approach, although Mozilla-only. This project does raise a
bunch of issues about how to solve this problem, number one being if
every record in the recordset results in a new network request, it's
going to be very slow (and XULRecordSet is very slow). Tried to
highlight some of the issues here:
Think and interesting trial application to build would be something
for managing a list of users, with paged result results and CRUD
functionality using AJAX / io.bind. And what if multiple clients are
managing the list at the same time? Have yet to see anyone discuss
this problem seriously, in relation to AJAX.
More information about the Dojo-interest