Here are some scenarios I'd like to see handled coherently, in no particular order. I'm a bit rusty, so pardon me if some of this has been done or I'm misremembering details. If we can factor out which of these are covered by the new model, that would be helpful to planning any additional work once those changes are merged with -dev
1) Separate dispatch logic from rendering logic (this is in part what leads to the horrible navigation conflation of menu and body) The request-handler pipeline would be cleaned up to perform: - Setup/error handling - Action handling - URL processing and tree manipulation - This can include handling URI arguments - Render the widget tree = This makes it much easier to reason about URLs during rendering because you know both the URL and the state of the tree at all levels of the hierarchy. You can search up and down the hierarchy from any point do perform processing because the tree mutations are all complete. It's also now possible to have the URL cause side effects to the widgets and potentially to the database. = This also means teasing apart the current dispatcher model to some degree. Perhaps this has already been done in the new navigation model. 3) A standard way of mapping url parameters to widget state - Slava and I had a nice discussion around this awhile back. The idea is to design a simple namespace policy for widgets in the hierarchy to accept state-changing data from the URI parameter list as part of the above URL handling protocol. Widgets would could automatically have slots populated with data from parameters. (There are subtleties with namespace conflicts in the hierarchy, of course). 4) An action interface where we can fire an action and render to a new URL. The action relies on the prior state of the tree, but the URL can reconfigure the tree. Maybe this can be hacked easily in the current model, but I don't think it's pretty. There should be a clean API. e.g. (render-redirection-link action url name &rest args) 5) I've never really understood the relationship between the token path and the url path... :) I think that's all for now. I'm sure there are other problems TBD. Oh, I have a reasonably stable dynamic-navigation element that allows you to dynamically add/remove elements from a navigation element. If that hasn't already been in the current tree I can promote it. Cheers, 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 -~----------~----~----~----~------~----~------~--~---
