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.
> When clicked, the onclick javascript chooses to do > AJAX or a standard load based on whether the link URL matches the current > URL. Yes, that's a good way of doing it (the action will have to be stripped off before doing the comparison). > We should add a render-simple-link which renders a standard link > without an action but is state sensitive. I'm not sure what this is for. Why not just use an href? Presumably in this case you'd go to a different page so that it's ok for the query string to be lost. > I'm upgrading to the latest weblocks over the next week or two so > I'll get up to speed on what's going on and can provide some input > into this discussion if it's helpful. When you're done, could you briefly post about the experience? I'm curious how much effort moving from a private branch back into official weblocks involves. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
