I had intended the parameter part for GET parameters only. What would be the implications for POST parameters? Perhaps pass that to the update function? What should be the default behavior?
Ian On Mar 22, 2009, at 8:37 AM, Ian Eslick wrote: > >> >> I would suggest careful naming here -- how about uri-parameters- >> mixin and >> :uri-parameter (if I understand it correctly, it is not a predicate)? >> >>> > > That's a better name, thanks. > >>> after the update-children call during widget updating." >> >> This looks good -- but I think another GF is necessary, called right >> after update-widget-parameters. Most of the time I will want to leave >> update-widget-parameters alone (it does what I want), but I will >> need to >> do some extra work after my widget's slots have been set. >> >> An example: a search widget with a slot (query :uri-parameter "q"), >> where I don't want to override update-widget-parameters, but I do >> need >> to define a method, say, update-state-after-parameters that will >> perform >> the query and update the widget's state. >> >> Perhaps :after methods on update-widget-parameters are enough -- I'm >> not >> sure. I'd have to write code that uses it to find out. > > How about we stick with :after methods unless there is a good reason > to do otherwise? It's easy enough to add later. > >> >> I don't understand how this will work -- we don't really have a >> notion >> of a "current uri". >> > > Doesn't render-link reconstruct the current URI as the base for > creating links? The URI the server receives determines the state of > the tree and is immutable except via client actions or redirects, so > it should be easy to reconstruct and used in links that are not > generated by render-link. Right? > > >> [...] >>> ================================== >>> >>> URL Fragment Protocol Spec: >>> >>> To review, URL fragments are used for: >>> 1) Supporting back button state changes without page loads >>> 2) Recording client-side state changes w/o server side updates >>> 3) Bookmarking ajax state >> [...] >> >> As I wrote before, I believe this should be done using a library (I >> suggested the YUI Browser History Manager). And since I don't need >> it at >> present, I won't comment for now. >> > > I think that my proposal is compatible with these (they basically pack > and unpack the fragment for you + handle the polling issues for back > button and pastes) and the specific infrastructure I described is very > likely to be required for the JS library in order to interoperate with > weblocks. > > 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 -~----------~----~----~----~------~----~------~--~---
