Re: The "Mobile me" web apps
Re: The "Mobile me" web apps
- Subject: Re: The "Mobile me" web apps
- From: Ricardo Parada <email@hidden>
- Date: Wed, 11 Jun 2008 20:24:56 -0700
On Jun 11, 2008, at 6:19 PM, Mike Schrag wrote:
As far as adopting ERX, I don't know enough about what your
framework does to give suggestions.
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.
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.
By the way, what does ER in all the wonder frameworks stand for? :-)
The main point I would ask about is how you are addressing the
backtrack cache handling, as this is one of the primary features of
the Wonder Ajax.framework (which was adopted in a slightly older,
but similar, form in 5.4). We do quite a bit of painful munging
magic in the app backtrack cache handling to make Ajax.framework
work, so you might want to compare how you're handling these
problems with your own solution (which I'd be interested to hear
about if you have an alternate solution). Wonder also obviously has
quite a bit of users (including Apple for some internal apps), so
you obviously benefit from community development on the framework.
Again, though, not knowing your framework, it's hard to give more
specific pros/cons.
Hmm... backtracking... :-)
I don't know if I'm handling this the best way. Or maybe I'm not
handling it. It depends on what you mean. :-)
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.
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 :-)
- Ricardo Parada
+
_______________________________________________
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