Re: The "Mobile me" web apps
Re: The "Mobile me" web apps
- Subject: Re: The "Mobile me" web apps
- From: Mike Schrag <email@hidden>
- Date: Wed, 11 Jun 2008 21:10:31 -0700
In my framework, I also have an AjaxUpdateContainer with similar
bindings. For example, I have an optional elementName binding which
defaults to "div". I also have an id binding which in your
AjaxUpdateContainer is called updateContainerID I think. In mine I
think I just call it id.
AjaxUpdateContainer for us has an "id", which is referred to as
"updateContainerID" on things that refresh it (like AjaxUpdateLink or
AjaxSubmitButton).
What I don't recall seeing in the demo at WOWODC is a binding called
inputContainerID. My AjaxUpdateContainer has a binding called
inputContainerID which is the ID of an html element on the page that
contains input elements. For example, it could be a row (tr) or a
div which contains text fields, checkboxes, pop-up lists, etc. If
an inputContainerID is specified I put the values for the input
elements in the form values that I send in the request. I also send
additional info, i.e. the names of the submitted elements in the
request because as you know, check boxes when unchecked are not
included in the form values. So by sending in a list of the
elements that are being sumitted I can handle the partial form
submits.
So in Wonder, partial form submit is currently flagged on a single
form element (what I found was that most people really only were
submitting a single changing value for partials), though the way it's
implemented doesn't actually require only one ... It's roughly the
same deal, though.
By the way, what does ER in all the wonder frameworks stand for? :-)
WONDER is some back-doored acronym from years ago "WebObjects Nodes
for Distributing E-Resources" ... Don't ask me why. I have no idea
what the "er" actually stands for though -- maybe "e-resources."
Here's what I recall I'm doing in my Ajax framework. When I
receive an ajax request I know it's an ajax request because of a key
in the form values (i.e. the key that lists the input elements being
submitted). When handling an ajax request I then create a special
AjaxContext. This class overrides contextID() to return the
requestContextID. In other words, the contextID is not changing as
you get ajax requests. So for example, after the page is rendered
let's say I have contextID of 5. I then get an ajax request and
generate html which may contain URLs with context IDs in it. The
context IDs in those URL happen to be also 5 because the contextID
is basically not being advanced. My AjaxSession class overrides
savePage() and does not call super.savePage() for ajax requests.
This prevented me from gettting the user has backtracked too far
error.
We're doing something more complicated, but I'm not really convinced
it's any different (when it's all said and done) than what you're
describing ... I have to ponder this some. It's equivalent in spirit,
at least. There's at least one case that I'm a little concerned about
with this approach, but I have to think on it some.
Now, if the user clicks the back button in the browser, you got me.
I'm not handling anything like that. And most likely bad things
will happen. :-S :-)
Actually, this should work, because I think our implementations end up
being the same from the backtrack cache perspective, which is that
back button should take you back to the previous non-ajax page and
work just fine.
ms
_______________________________________________
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