[...] > I have a long specification written up below; I think I've dealt with > the major design issues except the specific encoding restrictions on > parameter names and values and the nitty gritty of cross-browser > fragment updating. > > If anyone wants to take the time to read through and ask probing > questions or suggest how to encode hash parameters, I'm all ears.
Here goes: > ===================== > > URL Parameter Protocol Spec: > > Enabling parameter updating via a mixin class parameter-mixin. > defwidget can add this to the superclass list of widgets when any slot > contains :parameter-p name where name is the parameter string > associated with the slot value. The default methods for non > parameterized widgets simply return nil or do nothing. I would suggest careful naming here -- how about uri-parameters-mixin and :uri-parameter (if I understand it correctly, it is not a predicate)? > The reason for the mixin is that we add overhead to URL processing and > generation when we use automatic parameterization. Users wishing to > customize this can simply override current-parameters and update- > parameters for their specific widget, ignoring the metaclass machinery. > > > Incoming URLs: > > (defgeneric update-widget-parameters (pwidget parameters) > "Given an alist of parameters, widget updates its state > appropriately. The default method for plain widgets does > nothing. The default method for parameter-mixin uses a > method (parameter-slot-map that is automatically defined by > the macro to get the list slots to update and the associated > parameter names. > > The default method presumes that parameters take the form of > (format nil "~A-~A" (class-of widget) slotname). This method is > called > 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. [...] > Generating the Current URL: > > If you want to generate a link that encodes the link's side effect > into the url parameter arguments, then we need a way to easily > generate the current URL for the other widgets in the post-action, > post-parameter processing state. However, the contract is that the > state of the hierarchy given a URI should mirror the semantics of that > URI. So given the current URI and parameters, all we need to do is > merge the desired side effects into the current URI. Let's just give > the user a default helper function: > > (defgeneric merge-with-current-uri (webapp new-params) > "This is a webapp scope method that implements a simple policy for > taking the union of all provided parameters, giving preference > to changes.") I don't understand how this will work -- we don't really have a notion of a "current uri". [...] > ================================== > > 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. --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 -~----------~----~----~----~------~----~------~--~---
