Ian Eslick <[EMAIL PROTECTED]> writes: > 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.
This sounds very reasonable. And let me add another requirement: I'd like to have a "breadcrumbs" widget, displaying the current position within the entire navigation system. E.g. something like: Home > Articles > World > Today > Article-X (with links to all upper levels) I couldn't figure out how to do it with the current system without baking in lots of assumptions about how URLs were going to look like in multiple places. > 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). I don't see this as very important -- but perhaps it is just me. I never had a need for widgets accepting parameters -- the current model with a dispatcher that can eat url-tokens and pass them on to created widgets is OK for me. Well, I would still like a better interface (I know it's not lispy, but I keep thinking of django's regexps with parameters), but I could live with the current one. I also think this is relatively minor in comparison to #1. > 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) Ah, yes! Please! This is *exactly* what I hit yesterday, I wrote about flows interfering with navigation. Your #4 would allow me to define an "admin" action that would replace the root navigation with the admin interface and redirect the user to a URL appropriate for the admin interface, instead of landing him in the middle of nowhere. [...] > 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. That's another thing I needed -- but before I invest time into the current system, I would like to know if it is going to last... --J. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
