Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A RESTful configuration editor would be very useful #3

Closed
GoogleCodeExporter opened this issue Mar 25, 2015 · 22 comments
Closed

A RESTful configuration editor would be very useful #3

GoogleCodeExporter opened this issue Mar 25, 2015 · 22 comments

Comments

@GoogleCodeExporter
Copy link

I think that the configuration editor is a very clear example of an application 
that would benefit 
from RESTful URLs (e.g. /seaside/config/examples/counter). It could also be an 
example of how to 
provide them.

Original issue reported on code.google.com by renggli on 2 Mar 2008 at 8:14

@GoogleCodeExporter
Copy link
Author

Original comment by renggli on 2 Mar 2008 at 8:19

  • Added labels: Type-Feature
  • Removed labels: Type-Enhancement

@GoogleCodeExporter
Copy link
Author

I dont fully understand what is mentioned with
RESTful URLS.

Original comment by obi...@gmail.com on 3 Mar 2008 at 8:38

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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.

Original comment by renggli on 3 Mar 2008 at 8:46

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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

Original comment by obi...@gmail.com on 25 Mar 2008 at 9:25

  • Changed state: Started
  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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:)

Original comment by renggli on 26 Mar 2008 at 6:43

  • Changed state: Fixed
  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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.

Original comment by philippe...@gmail.com on 26 Mar 2008 at 8:12

  • Changed state: Started
  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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

Original comment by renggli on 26 Mar 2008 at 8:16

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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

Original comment by renggli on 26 Mar 2008 at 8:19

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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

Original comment by philippe...@gmail.com on 21 Apr 2008 at 7:03

  • Added labels: ****
  • Removed labels: ****

1 similar comment
@GoogleCodeExporter
Copy link
Author

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

Original comment by philippe...@gmail.com on 21 Apr 2008 at 7:03

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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

Original comment by philippe...@gmail.com on 26 Apr 2008 at 9:39

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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!

Original comment by obi...@gmail.com on 27 Apr 2008 at 6:59

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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

Original comment by philippe...@gmail.com on 27 Apr 2008 at 8:37

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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

Original comment by conra...@gmail.com on 29 Aug 2008 at 10:25

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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

Original comment by philippe...@gmail.com on 29 Aug 2008 at 5:49

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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

Original comment by conra...@gmail.com on 29 Aug 2008 at 6:39

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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.

Original comment by conra...@gmail.com on 29 Aug 2008 at 6:57

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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

Original comment by renggli on 13 Sep 2008 at 2:18

  • Changed state: Fixed
  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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.

Original comment by philippe...@gmail.com on 1 Nov 2008 at 5:59

  • Changed state: Accepted
  • Added labels: Version-Seaside2.9
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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

Original comment by jfitz...@gmail.com on 1 Nov 2008 at 6:03

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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.

Original comment by philippe...@gmail.com on 1 Nov 2008 at 8:24

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

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

Original comment by renggli on 12 Dec 2008 at 1:10

  • Changed state: Fixed
  • Added labels: ****
  • Removed labels: ****

dalehenrich added a commit that referenced this issue Oct 7, 2020
PIck up the latest from the master branch (1 year's worth) ... Squeak3.5 is only travis failure and for this work I will only be monkeying with GemStone code
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant