Scott L. Burson wrote: >>> (Is this the "AJAX navigation issue" you're referring to, Leslie? It >>> doesn't seem to be AJAX-specific.) >> >> Yes. The problem is not that the client has the wrong idea of >> the URI but that the server has no way in an AJAX request to >> get the current (last used) URI. So there can't be any dispatch. > > I'm not sure we're talking about the same things. I don't see how > AJAX is involved in my situation. The navigation menu is rendered > with non-AJAX links, of course. One of the selections brings up a > login widget whose ON-SUCCESS method (the default) calls ANSWER. I > have a simple flow that first yields to the pre-login navigation, then > when that answers true, yields to the logged-in navigation. So the > user clicks only twice here, once to select "Log In", and then to hit > the submit button on the login quickform. Where in that process would > there be an AJAX request?
When the Submit button is hit, unless you disabled that behavior in some way or you're running a client without Javascript. > What I wanted was a main menu that would have one set of > options when the user wasn't logged in, and a somewhat different set > of options after login. It was easy enough to set this up the way I > did, except for the problem I have described. Ah, I see. > I can see a couple of other ways to do this. One is to have a single > navigation where (a) those selections whose panes depend on session > state (such as whether the user is logged in) are implemented with > custom widgets which override UPDATE-CHILDREN[*] to select the > appropriate child widget for the situation; and (b) changes in the > displayed navigation menu are accomplished by setting > NAVIGATION-HIDDEN-PANES. [* Or maybe plain widgets with appropriate > WIDGET-PREFIX-FNs.] Yeah, I would probably use a custom navigation in some way or another that depended on what exactly I was trying to achieve. > Really, though, I don't think the way I did it is all that bad by > comparison. But perhaps you have yet another approach that is > superior to all of these? I can't object. There are a lot of ways to do things in Weblocks and the decision which way is best depends a lot on the context and desired behavior. Leslie -- You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.
