I need to expose the state of some widgets via a query string (for example, for dataseqs it would be sorting and paging information). As an example, viewing page foo will get me:
/foo?sortby=name&order=asc&page=3 Dataseq is my major motivator, but I have some other things that need to be exposed this way. I haven't followed development for a while so please tell me if the following makes sense. In src/widgets/widget/widget-mop.lisp, add a new expose-via-query-string-p slot to widget-slot-definition-mixin. This lets the programmer declaratively state which widget slots should expose their state to the URI. Because a single page may contain multiple widgets with the same slot names, when exposed to the URI the slots may be prepended by the widget's id. Also, because the programmer may want to turn the behavior off for some widgets, it's probably a good idea to add expose-via-query-string-p slot to widget class itself, and to look at it before serializing widget slots to the query string. The next step is rather simple. Every link and every form will have to be appended with the state of the rendered widgets. One simple way of doing it is collecting a list of widget instances/slot name pairs during rendering, and then having hunchentoot rewrite the URLs to add the slots and their serialized values to the query string. I can then do: (defwidget color-chooser () ((color :initform 'red :expose-via-query-string-p t))) When I render a page that has color-chooser in it, I get /foo/bar?color=red. Obviously, if the user types in /foo/bar?color=blue, weblocks will automatically update the slot in the color-chooser. Thoughts? Will this work with the new additions/modifications to weblocks? On a different note, could someone take a little time to write a summary of the new additions/modifications to weblocks? I don't want my branch to hopelessly diverge from offical weblocks, and maintaining everything in sync is hard (what will I have to change in my app and how much work will it involve?). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
