Hi All,
I've forgotten where we last were on the discussion of using URL
fragments to remember widget state. The inability to use the back
button and the inability to bookmark without creating a conventional
hierarchy on top of the navigation/menu widget structure is becoming
an issue for my site and I'd like to fix this.
Last time this came up, I was waiting on the new navigation changes,
which seem like they're finally converging (at least enough that I can
embark, hopefully with help!) on an effort to implement this
functionality. Mint.com is a partial inspiration as it deploys an
AJAX model that I think would work perfectly in Weblocks.
Here is a short summary of my thinking; I am of course open to
alternatives and don't want to miss any work along these lines that's
been done or is happening.
I want:
1) A standard and easy way of exploiting URL parameters
2) A standard and easy way to exploit URL hash fragments
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. Perhaps this is already effectively
there? Individual users can decide how to create hard links that
generate these parameters.
The second is a little trickier, although there are libraries that
help manage the javascript side of things.
a) Define a method that generates a URL hash tag from the current
state of the widget hierarchy. This can be done as part of the
rendering process. Perhaps with an 'append' method combination
similar to the dependencies tracking? (Users can accept a default
'append' model for mixing multiple widget state or customize their own)
Keeping the URL synced to the widget state...
b) On standard loads we simply send the URL hash as an :after-load
script that sets the URL hash appropriately. The server state mirrors
the client URL.
c) On ajax loads we do the same, but we'll need to mix the parameters
from dirty rendering with the parameters of the prior load. This
means that the session keeps the result of the last append method and
a map of widget->identifier results and simply splices in the changed
widget's changed parameters.
Keeping the server state synched to the URL state...
d) When the user hits the back button and pulls a different hash
identifier from the browser history that doesn't change the URL, the
client does an AJAX call to a special action which updates the widget
tree from the hash code. This is an extension to the first method I
described for standard parameters
e) When the back button or a paste results in a new URL + hash, the
server only sees the old URL, so we're going to be rendering the
server's last known state for that base URL. When the hash code
script runs on reload, we compare it to the hash code in the URL and
if it differs, use the method in 'd' above to update the view (unless
there is no existing hash, then we used the one supplied).
There are a bunch of issues here in how to manage the parameter and
hashcode namespaces. I don't want to over-commit to any given method,
but I do want a reasonably clean default solution.
1) We are able to send the aggregate hash code inside a reserved URL
parameter; perhaps state='hashcode-contents'. This helps in the case
where we want to generate a hard link to another navigation element,
but tell it to change its state.
2) We have a conventional way to mix widget server-side states. We
may also want conventional client-side hash state; so need to allow
for that too.
The easiest method is to find some string format that can fit inside a
standard parameter which has the following (rough) grammar:
hash = <server-state> [ <client-state> ]
<server-state> = <begin>widget+param=value[,...]*<end>
<client-state> = user defined, not <start>/<end> and URL-encodable
<start> = {
<end> = }
e.g. a fragment from mint.com
#location:{%22level%22:1,%22category%22:1,%22startDate%22:%...}
We either need a unique widget identifier for a given state of the
tree and a given widget needs to agree on its own state vars; or we
need global agreement on the parameter namespace. I think the former
is less likely to cause horrible collisions. We can detect duplicate
widget names pretty easily, but not collisions.
Thoughts?
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
-~----------~----~----~----~------~----~------~--~---
