I haven't done anything along these lines yet. I did do some friendly URL work, but that was mostly custom render-link + dispatcher to strip tokens instead of AJAX links when I needed to change state.
I suspect what Leslie was referring to is a recent e-mail where I expressed interest in implementing the URL hash trick to clean up some back button issues for my application while reducing page load and redirects. What you are describing sounds like what we talked about last summer and I think it's a nice way to generalize the friendly URL idea. I think the rendering pipeline can now handle the case where there is an action and a different destination URL in the link, correct? Then render-link can simply render the current widget-url + current parameters + action. When clicked, the onclick javascript chooses to do AJAX or a standard load based on whether the link URL matches the current URL. We should add a render-simple-link which renders a standard link without an action but is state sensitive. It probably behooves us to have a discussion generally about the different kinds of links we can generate, how they interact with state and ajax updates, and what the right general interface is. 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. Ian On Feb 16, 2009, at 7:17 AM, Vyacheslav Akhmechet wrote: > On Mon, Feb 16, 2009 at 3:46 AM, Leslie P. Polzer > <[email protected]> wrote: >> You want to connect with Ian to avoid duplicating work. > Did Ian mention doing this? I spoke to him about this some time ago > (back in the summer) but I don't think I heard anything about this > since then. > >> If the ID is an ephemeral symbol then it will not be an URL >> that can be shared. > Yes. Resolving by widget ID would probably happen only if there are > two slots with the same name which should be rare enough. It would > then be up to the programmer to provide the IDs for appropriate > widgets. > >> How is this going to mix with AJAX updates? > For the updates to show up on the query string, the relevant links and > forms would have to be AJAX-free (at least until someone works on > integrating the URL hash thing into weblocks). This might be done > automatically (changing a state of a slot that is marked to be > serializable into the URL would force a refresh), or the burden might > be left on the user (which isn't that big of a deal, it seems). > >> Gladly, but you need to be a bit more specific. Are you talking about >> upcoming merges, or a certain window that has already gone by...? > I was thinking about everything from two months ago until now (plus > upcoming changes). It's obviously difficult to come up with a detailed > changeset (I can just look at the hg log), so instead if any > reasonably major features come to mind, it'd be great if you could > mention them with a very brief overview. I can then dig in deeper > myself. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
