Ian Eslick <[email protected]> writes: > On Feb 16, 2009, at 8:37 AM, Vyacheslav Akhmechet wrote: > >> On Mon, Feb 16, 2009 at 8:24 AM, Ian Eslick <[email protected]> >> wrote: >>> Then render-link can simply render the current widget-url + current >>> parameters + action. >> It's not quite that simple because at any given point render-link may >> not know all of the current parameters. If I have two widgets on a >> page that contribute to the query string, at the time widget 1 is >> rendered it knows nothing about the parameters of widget 2, so if it >> renders a link without that knowledge and the user bookmarks it later, >> the information about the state of widget 2 will be lost. The easiest >> fix I could think of for this is collecting all the query parameters >> during rendering, and then rewriting the html with Edi's url-rewrite. > > I don't know if the new navigation has implemented this, but I have > been advocating for some time that we have a full pass through the > tree happening between action processing and rendering. This can > update the dispatchers/selectors as well as extract and collect > parameter information, etc. There are lots of reasons to have hooks > into a tree-global operation so we can do things that don't depend on > rendering order. Rendering should do nothing but serialize widgets.
I was about to mention that -- in my navigation work the tree is walked twice: once to shake it down, e.g. modify based on the current URL, for example, and another time while rendering (however, note that there are no "dispatchers" in my rewrite, only selectors, the actual get-widget-for-tokens functionality being delegated to a method). There are lots of things this can be used for -- as an example, I figured that it should be up to the most specific widget to define the HTML page <title>. "Most specific" as defined by "the deepest widget in the tree that wishes to set the title". The title gets extracted during the tree shakedown pass, so we have it nice and ready for rendering. It worked out for me quite well. You could use a similar approach to gather query string information, and then render all links appropriately in the second phase. --J. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
