Re: Wonder Ajax
Re: Wonder Ajax
- Subject: Re: Wonder Ajax
- From: Mike Schrag <email@hidden>
- Date: Thu, 3 Aug 2006 09:41:22 -0400
I have been experimenting with some of these components, and they
really increase the usability of the application. For the
interactive components, however, what is the gist on how Ajax
performs the form submissions without getting into a backtracking
problem? Is it stable, I humbly inquire.
As far as stable, this code is all relatively new and I don't know
how many people are actively using it yet, but I use it on a couple
internal systems and it has been working fine for me for a few
months. As far as the explanation of HOW it works, it's kind of a
complicated answer, so I'll attach the javadoc explanation that I
wrote up (world's largest method javadoc :) ) at the bottom of this
email.
The first problem I got into was that it wasn't refreshing the
screen to show the Array after the addUser (or removeUser) action
was run . . . because it wasn't refreshing the page. So i have an
empty form named form1, and in the onDrop method of droppable I put
in document.form1.submit();. Then the page would refresh and
everything looked fine.
Right, so AjaxDroppable doesn't automatically do a container update,
because that's not necessarily an intrinsic behavior of a droppable.
However, you can use all the standard prototype/scriptaculous tricks
along with some of the other Wonder Ajax tags to do this. I just
checked in a new example of two draggable/droppable lists that you
can drag/drop between. There are several ways to do this, but I did
a simple AjaxDraggable/AjaxDroppable version. The slightly fancier
one would be to use AjaxSortableList which gives fancier drag-over
effects. That you're doing a form submit is slightly suspicious in
Ajax World, but it certainly will work. The fancier way would be to
wrap your lists in an AjaxUpdateContainer and set your onDrop to call
the yourUpdateContainerUpdate() javascript function to make it do an
Ajax refresh. You can also make your onDrop actually move the
element between the lists on the client side as well and avoid an
area update all together.
For my edification, does onDrop happen before or after the
execution of it's form submission? Or are they synchronous?? Is
there a better way to refresh the page? Secondly, in my console I
see "Exception while sending response: java.net.SocketException:
Broken pipe" Everything works, but any hints on why the error's
coming up anyhow?
Just so the terminology is consistent, I wouldn't generally call it a
"form submission", unless you're referring to specifically your call
to form.submit(), because in the general case there is no Form object
-- it's dynamically constructing Prototype Request objects. If I had
to guess about the broken pipe, it might be that the Ajax request
that's notifying your droppable is getting its response pipe broken
by the form.submit() that you're calling in onDrop, but you would
have to do some testing to see for sure (i.e. you could delay the
form.submit() with a n alert('') and see if the broken pipe goes away).
And for the explanation about how backtracking errors are avoided,
there is a new piece in Wonder called the "page replacement cache"
that is used for Ajax requests instead of the normal backtrack
cache. This is also, by the way, known as "the huge pain in the butt
to get working properly without breaking other things cache":
"Page Replacement cache is specifically designed to support component
actions in Ajax updates. The problem with component actions in Ajax
is that if you let them use the normal page cache, then after only 30
(or whatever your backtrack cache is set to) updates from Ajax, you
will fill your backtrack cache. Unfortunately for the user, though,
the backtrack cache filled up with background ajax requests, so when
the user clicks on a component action on the FOREGROUND page, the
foreground page has fallen out of the cache, and the request cannot
be fulfilled (because its context is gone). If you simply turn off
backtrack cache entirely for a request, then you can't have component
actions inside of an Ajax updated area, because the context of the
Ajax update that generated the link will never get stored, and so you
will ALWAYS get a backtrack error. Enter page replacement cache. If
you look at the behavior of Ajax, it turns out that what you REALLY
want is a hybrid page cache. You want to keep the backtrack of just
the LAST update for a particular ajax component -- you don't care
about its previous 29 states because the user can't use the back
button to get to them anyway, but if you have the MOST RECENT cached
version of the page then you can click on links in Ajax updated
areas. Page Replacement cache implements this logic. For each Ajax
component on your page that is updating, it keeps a cache entry of
its most recent backtrack state (note the difference between this and
the normal page cache. The normal page cache contains one entry per
user-backtrackable-request. The replacement cache contains one entry
per ajax component*, allowing up to replacement_page_cache_size many
components per page). Each time the Ajax area refreshes, the most
recent state is replaced*. When a restorePage request comes in, the
replacement cache is checked first. If the replacement cache can
service the page, then it does so. If the replacement cache doesn't
contain the context, then it passes up to the standard page cache.
If you are not using Ajax, no replacement cache will exist in your
session, and all the code related to it will be skipped, so it should
be minimally invasive under those conditions."
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden