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. >> 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. Sorry, that was an incomplete thought. I'd like to link to a particular tree state via a function like (render-widget-link named- nav text). The idea is to allow certain widgets to export a name so I can find and/or link to them easily. This way I can refer to related widget state programatically rather than having to reconstruct the URL at each rendering point. This idea can be extended to link to a tree state + widget state by adding a configuration arguments, such as (render-widget-link mail-reader "Link to mail-reader message" :config `((mail-reader :message ,msg-id :state :reply) (mail-chat-sidebar :update))) The webapp can build/maintain a lookup table for widgets with names. Two things I kept doing was finding ways for one widget to find another. The other was writing functions to compute the URL for particular tree state when I wanted to do a link from one tree state to another. This was very ad-hoc and for friendly URL schemes a common operation. >> 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. I haven't updated my branch since at least September! I'll let you know. Ian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
