On Sun, Jan 23, 2011 at 11:15 AM, Leslie P. Polzer <[email protected]> wrote: > Scott L. Burson wrote: > >> In my case I have two navigation widgets, one with a "Log In" >> selection, the second without it but with some additional selections. >> There are two calls to REDIRECT needed. One goes in the :ON-CANCEL >> action of the login. For the other, I have a "Log In" selection on >> the second navigation which is declared to be hidden, and which >> instead of an action has a function that does the REDIRECT with :DEFER >> NIL. So when the second navigation is installed in the widget tree, >> it receives the "log-in" URI token that is still hanging around, and >> then forces the redirect. >> >> (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? > Therefore this problem will always show up when a navigation > widget is inserted into or removed from the widget tree, > unless it happens in a non-AJAX request. I think I understand what you're saying, but again I don't think this is my situation. > I've never needed to do this, actually. Can you come up with > any situations where you really need to change the nav structure? I'm not at all sure that I'm doing this in the best way -- I'm very much still learning how to use Weblocks -- but it does seem to be working. 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. 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.] The other way would be to define a custom navigation subclass and override GET-WIDGET-FOR-TOKENS. Care must be taken to clear STATIC-SELECTOR-CACHED-PANES when the state changes. If this is considered a desirable approach, I think it could be better supported by breaking out the computation of the effective pane (in GET-WIDGET-FOR-TOKENS) into its own method, so one could override just that. 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? -- Scott -- 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.
