[Seaside] Truly Opaque URLs

[Ramon Leon]

> I disagree. I am not really a developer. But I care.
> I also don't know what study has been done to determine such. 
> In the experience of some developers on the apps they have 
> done. That might be the case. But users silence on the issue 
> doesn't mean that anything but silence. Voicing an opinion to 
> Amazon, eBay, my bank or whatever wouldn't change a thing. 
> Most people understand that and keep silent.
> And that is regardless as to what irritates any specific user.

Users don't hang out in the Seaside mailing list, you're enough of a
developer that aren't a user.

> I watched a video with one of the Django developers. He spoke 
> about how often visitors to their website attempted 
> modifications to the URLs. So they wrote code to specifically 
> catch such instances and to understand them and provide a 
> positive experience to their users. I am not advocating such. 
> But just stating that the opinions expressed by many here are 
> not the only opinions or experiences.

That's interesting, do you have a link?

> I am not worried about anybody fiddling with the _s, _k, _n 
> parameters.
> However, I don't see any reason that they should belong in a 
> Seaside URL. To me they seem antithetical to the "we don't 
> need to marshall parameters" argument of Seaside. The only 
> difference is that you don't have to think about the params 
> or the marshalling. But somebody did at some point.

Parameters have to be marshaled, Seaside's feature is that you don't have to
do it, the framework does it for you.  They belong in the URL because the
URL is the only place to put them, the only question is do you munge them
into the path, or just stick them on as parameters.  URL's are meant to have
parameters, there is nothing unRESTful about them, so it makes sense to pass
parameters as parameters.

> And then I don't believe that developers opinions or 
> complaints about such are invalid simply because they are 
> developers. The majority of people don't care. Fine. The 
> majority also uses Windows. That doesn't make their opinion 
> about OSes superior or correct.

It's not that developers opinions are invalid, it's just that we tend to
worry about things that just don't really matter to most users.  URL's, just
don't matter to most users, and most users are who we're writing apps for.
More importantly, passing the key as a parameter rather than a mixing it
with the path is no more or less ugly, but it's vastly simpler to implement
and automate, and automating URL management is the whole point.

> Despite any other reason for my idea. Why keep the 
> parameters? Besides that you don't have to do anything in 
> order to keep them and you have to do something to not have them?

Do you have something simpler in mind?  What you're suggesting isn't simpler
than parameters, it's more complex.  You want to mix a parameter into the
path, this means I'd have to think about this every time I started playing
with the path, or parsing the path, it'd make my job harder.  The _s and _k
parameters don't get in my way, messing with the path however, would.  I
much prefer named parameters over parsing paths.

> If they weren't there already and there was just a simple 
> short opaque id at the end. Would argue for them?

Yes, because named parameters are simpler than parsing a path.

> To me legacy is the only reason for them. And that isn't the 
> best of reasons. It is a valid reason for a season. But there 
> is a lot of legacy code that is regularly cleaned up and 
> removed or changed.
> 
> Jimmie

It's not legacy, as Lukas pointed out, Seaside used to do it the way you
suggested, the current way is the new way, and it's better.  I really just
don't see how mixing meaningless state information into the path somehow
makes the meaningless nature of the param more appealing.  

More to the point, I don't care about the URL being appealing, I care about
the application actually working, and being easy to develop.  I know of no
way to have meaningful parameter-less pretty URLs that isn't completely
manual, so I'll choose the automated solution Seaside offers and just worry
about solving the real problem at hand, writing applications that solve
users problems.  I've never heard a user say his problem was that URL's
weren't pretty enough.

Ramon Leon
http://onsmalltalk.com