[Seaside] Truly Opaque URLs

[Jimmie Houchin]

Adrian Lienhard wrote:
> I think in this discussion we should distinguish between closed
> applications and public web sites (or applications that are part of a
> web site). In the former case I don't care at all about the URLs, and
> only care about bookmarking in very specific situations because it
> usually does not make sense.
> 
> On the other hand, on a public web site it matters. It matters for
> example for search engines. If each link looks differently although it
> points to the same page, this is not good. Also, you don't want that the
> session key of the bot shows up in search results. You want to make
> important keywords be part of the URL, you want URLs to be short so that
> people can easily mail them around (and no, I don't buy the argument
> that also Amazon has unfriendly URLs).
> 
> Out of the box Seaside is not very good at such things, but then,
> Seaside is for building web applications, not web sites.
> However, in case you happen to use Seaside for web sites (as we do for
> www.cmsbox.com for example) it is not too hard to tweak it.

Hello,

I think it would be wonderful if some of the experts here could do a
tutorial, how-to, best practices document, or some sort of documentation
for using Seaside for web sites, as opposed to web applications.

I know most of those here are using it for web applications where
Seaside is at its native best. But sometimes a simple web site is what
is desired or required. And I would imagine that many people who want to
give Seaside a try, what they really want is a web site, and a tool
which elegantly enables them to build it. We Squeakers, Seasiders
hopefully should never have to drop down to some other web framework to
do the web site thing.

I believe some good documentation this direction would help many who
look towards Seaside. It would also provide a place to provide answers
to these questions.

Would such be using this technique as expressed by Randall Schwartz?

Randal L. Schwartz wrote in the URL problems thread on December 8, 2007:
> As far as I understand the problem, for each component you could ask
> yourself:
>
>   Would I ever want to come back to *this* component in *this* state
>   as the result of a bookmark rather than a particular session?
>
> If the answer is "Yes", then the next step is for the component to add
> URL-based state information to the URL with
>   #extraPath: or #updateUrl:,
> and then recognize those state items with #initialRequest:.
>
> Perhaps a good demo of this would be handy.  Maybe I can come up with
> something, but Smarter People than Me might do it even faster and post
> it to one of their blogs (nudge nudge).

I would also imagine that many web site/applications are often share
characteristics of both.

Thanks for any insight or wisdom.

Jimmie