Second, is there any plan to expand on the RESTfulness
of Pier? I
mean, I'm not a die-hard REST person or anything, but there are
times it would be nice to use URL's. I think the above suggested
handling would probably be enough.
Yep, that's a requirement. Thanks that you reported this, I probably
wouldn't have noticed it myself.
One thing that makes me want this is the
difficulty of pointing to
another page in your Pier site from a custom component. I know you
have the #goto: message on anchor, but (1) I need it anywhere a URL
could be used, since I am using "html tag:" to do some tags not in
seaside (an HTML image map to be specific). And (2) the #goto:
message expects a structure that can be tough to get a hold of
sometimes. The easiest thing for me would be if I could simply
point my image map at the URL as a string, since that part is
public and I don't care if the user is logged in or not.
Glad that you ask. For the blog component I also felt the need to
have just the url and not only an anchor. I think I will need to add
that sooner or later. Shouldn't be too difficult though.
The Pier context object (representing the current browsing context of
the user) has now two additional methods:
- #url returns a REST-full instance of WAUrl. All session information
will is discarded when using this URL, but the current structure and
command and view are preserved. It is save to bookmark this URL and
to give it to your friends.
- #urlOn: what returns a Seaside URL triggering an action callback
that sets the receiving context. This URL can also be bookmarked but
should not be passed to your friends. As long as your Seaside session
is valid, it will remember all the state. After the Seaside session
expired the URL has the same effect as #url.