(No comment was entered for this change.)

I dont fully understand what is mentioned with
RESTful URLS.

This is a feature request by Paolo (check back on bugs.squeak.org to see the real owners). WABrowser is the only 
RESTful example application so far, unfortunately it is not portable and therefor other platforms lack a nice 
example for bookmarkable seaside applications.

Dispatcher and configuration editor are now RESTful!
try /seaside/config/examples/counter or /seaside/config/examples/
- Waiting for code review!

Name: Seaside-Development-Core-lr.17
Author: lr
Time: 26 March 2008, 7:42:08 am
UUID: 4a0d22cf-1d29-469f-8f77-768960458269
Ancestors: Seaside-Development-Core-obi.16

- moved up #initialRequest: to WADispatchComponent
- implemented the other half of RESTful dispatcher component (#udateUrl:)

Guys I hope you are not serious about this code. #initialRequest: alone as several 
problems.
1. It sends #asString which is no longer supported
2. It sends #asString. #asString converts the URL to a full URL which may include 
the scheme. Then it tries to pase the path again. This will fail in the case of a 
full URL with a scheme. Second it is schizophrenic because WAUrl aleady has a path. 

Sorry guys, but this is not acceptable code quality.

So what should you do IMHO:
- Make methods in WAUrl that do the path computation
- Write tests!
- Use those tested methods.

I completely agree. That's why I created: http://code.google.com/p/seaside/issues/detail?id=39

And ... ehh ... I am working on it (integrating long existing work)

Guys, could you have a look at:

Name: Seaside-Development-Core-pmm.21
Author: pmm
Time: 21 April 2008, 9:03:02 pm
UUID: 08b67c06-170b-425e-bbf6-2e53ecbbd7a4
Ancestors: Seaside-Development-Core-lr.20

Guys, could you have a look at:

Name: Seaside-Development-Core-pmm.21
Author: pmm
Time: 21 April 2008, 9:03:02 pm
UUID: 08b67c06-170b-425e-bbf6-2e53ecbbd7a4
Ancestors: Seaside-Development-Core-lr.20

It took me a moment to understand what Seaside-Development-Core-obi.22 does. AFAIK it
fixes cases like /seaside/tests. Is that correct?

Hmmm no, this is not fixed!
There was a problem if you type e.g. /seaside/config/examples/counter
and then use the close button => Exception!
Because in that case the handler instVar is not correct!

Ok, Seaside-Development-Core-pmm.24 sets the handler but displays the wrong URL after
"Close"

Can one create Seaside applications that use Restful URLs with this fix/update?

You can reproduce the problem by going to:
http://127.0.0.1:8080/seaside/config/examples/demo.rss

It seems that the same page is rendered no matter what extension I add on the end of the URL.

We're getting HTML in the browser by default.  Thus, we need some type of respontTo handler which looks at the 
headers or the type of content the end user wants to determine what type of content that needs to be displayed.  
For example, if the headers specify N, then we can invoke toN method (i.e.  headers RSS maps toRSS method, 
headers XML maps toXML method, and so on).  Lastly, HTML is the default.

Name: Seaside-Development-Core-lr.44
Author: lr
Time: 13 September 2008, 4:18:17 pm
UUID: 242cf6b3-a4c1-4f63-b6ee-2649a91de23d
Ancestors: Seaside-Development-Core-jf.43

- fixes a security issue in WADispatcherViewer
- made WADispatcher component fully RESTful

I'll have to reopen this issue, the following URL

/seaside/config/tests/alltests

gives me the error:

WAUnhandledNotificationError

Your request could not be completed. An error occurred.

 Issue 218  exists for that... not sure if you still want to leave this open or not.

That's a good question. I have already encountered situations where doing a #call: in
#initialRequest: would have been helpful.

However the configuration editor does not work in it's current state until that is
implemented.

As  Issue 218  is fixed, this one can be closed too.