On Mar 21, 2009, at 1:48 AM, Vyacheslav Akhmechet wrote:
> > On Fri, Mar 20, 2009 at 10:39 PM, Ian Eslick <[email protected]> > wrote: >> The first is pretty easy, I hope. As we walk the widget tree >> invoking >> navigation functionality, we have a new method that is called on each >> widget that can be specialized to extract URL parameters and update >> widget state without messing with rendering - essentially a potential >> action tied to each widget. > That's pretty low level. Would be nice to build some higher level > machinery to do it automagically by declaratively specifying that a > given slot should be serialized into the URL. Of course this could > always be built later by providing a default implementation of the > method. We talked earlier about the idea of extending the metaclass so this happened automatically, and I like that. It is as you say simply a change in the behavior of the default method so easy to add on. I'd like users to be able to extend it as well so what I proposed is the common subset. >> The second is a little trickier > This sounds rather complicated. I prefer to turn off AJAX when a > significant update is done to the widget hierarchy. So far it worked > pretty well for me, but my applications don't exactly push the > boundaries in terms of dynamic UI... From what I can tell this is the state of the art if you want to support the back-button as undo. I don't have a problem with the idea of a pure webapp, but my 100+ users really get confused when the back button doesn't undo a state change. The integration of friendly URLs doesn't fit cleanly into the framework when they are needed. It would be nice to be able to render a hard link that either: - Renders the current URL + a change to the parameter state (e.g. a filter) - Renders a new navigation URL potentially + parameters. Having methods you can call to link to a nav widget (that widget's navigation URL) that can also take parameters would be very helpful for more traditional apps. 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 -~----------~----~----~----~------~----~------~--~---
