Smalltalk › Frameworks & Tools › Seaside › Seaside General

SeasideRest and complex structures

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

EstebanLM

SeasideRest and complex structures

Hi,
I now understand how to use SeasideREST, and I'm trying to use it in a real application.

What's the problem? well... I want my rest filters to replace a portion of the screen and not all of it. Let's say I have this structure

app {
menu { option1, option2, option3, etc. }
contents: { hereAComponentForEachOption }
}

yeah, you need to be a little imaginative to understand what I'm trying to describe, but I think is clear: a main "div" with app, and then two divs, one with the menu and other with contents.
In my current application, if I press "option1" I can say contents show: option1Component.

So... I want to get same result if I do:

http://localhost:8080/app/option1

any idea how I can proceed?

thanks,
Esteban_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Intrader Intrader

Re: SeasideRest and complex structures

I have difficulties with the concept of REST alongside Seaside. According to
Fielding's dissertation Chapter 5.1.3, there cannot be any session state kept
by the server component.
In my opinion, what you are after is clean URLs as described in
http://onsmalltalk.com/clean-urls-in-seaside.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Olivier Auverlot

Re: SeasideRest and complex structures

The format of the seaside url is not compatible with REST. To build REST
web service, you must use Seaside-Rest that allow you to define handlers
for the differents commands of the HTTP protocols.

I hope that's help you

Olivier ;-)
www.auverlot.fr

> I have difficulties with the concept of REST alongside Seaside. According to
> Fielding's dissertation Chapter 5.1.3, there cannot be any session state kept
> by the server component.
> In my opinion, what you are after is clean URLs as described in
> http://onsmalltalk.com/clean-urls-in-seaside.
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Intrader Intrader

Re: SeasideRest and complex structures

In reply to this post by Intrader Intrader

Fritz Schenk <intrader.intrader <at> gmail.com> writes:

>
> I have difficulties with the concept of REST alongside Seaside. According to
> Fielding's dissertation Chapter 5.1.3, there cannot be any session state kept
> by the server component.
> In my opinion, what you are after is clean URLs as described in
> http://onsmalltalk.com/clean-urls-in-seaside.
>
Thist last link is unfortunately incorrect. It should be
http://onsmalltalk.com/clean-urls-in-seaside. I apologize for the mistake.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

NorbertHartl

Re: SeasideRest and complex structures

In reply to this post by EstebanLM

Am 19.04.2011 um 23:02 schrieb Esteban Lorenzano:

> Hi,
> I now understand how to use SeasideREST, and I'm trying to use it in a real application.
>
> What's the problem? well... I want my rest filters to replace a portion of the screen and not all of it. Let's say I have this structure
>
> app {
> menu { option1, option2, option3, etc. }
> contents: { hereAComponentForEachOption }
> }
>
> yeah, you need to be a little imaginative to understand what I'm trying to describe, but I think is clear: a main "div" with app, and then two divs, one with the menu and other with contents.
> In my current application, if I press "option1" I can say contents show: option1Component.
>
> So... I want to get same result if I do:
>
> http://localhost:8080/app/option1
>
> any idea how I can proceed?
>

Do you want to have a rest handler as a filter of your application that gives additional control or do you want to receive the whole thing via a rest dedicated handler?

Norbert

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

NorbertHartl

Re: SeasideRest and complex structures

In reply to this post by Intrader Intrader

Am 22.04.2011 um 20:49 schrieb Fritz Schenk:

I have difficulties with the concept of REST alongside Seaside. According to
Fielding's dissertation Chapter 5.1.3, there cannot be any session state kept
by the server component.
In my opinion, what you are after is clean URLs as described in
http://onsmalltalk.com/clean-urls-in-seaside.

The ST in REST denotes exactly this. State is always transferred to the client in order to enable it to do any action this state/page provides without any external source. As REST is an architecture this approach would get you the maximum out of it. This works best if state (context) is transferred from the client (sender) to the server (receiver) on a specific URL (method, although an URL encodes receiver and method). A big point in the architecture is orchestration. An invocation of an action includes e.g. the routing of the call and much more.

It works especially good if you have an resource centric view. The HTTP verbs map to CRUD operations and URIs act like IDs. On the other hand the application/dynamic/service view is kind of weakly defined by fielding. GET and POST are the ones that not only deal excusively with resources. While POST is explicitly not about resources GET lives a double life. Why? Because REST is an architecture (and not a service description) upon you base your application/service and there is no way predescribing or forcing an application/service into one distinct scheme.

I think it is often misunderstood that not being in fieldings description does not mean it must not exist. There is a place for server side state you should just avoid it where possible.

A good idea in such discussion to disambiguate the topic is to talk about RESTful URLs instead of just REST.

The funny thing about it is that REST has ST in it for a reason. I think that the REST architecture and smalltalk both think of the web as a big virtual machine. So it is very interesting to see where they fit together best.

my 2 cents,

Norbert

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Intrader Intrader

Re: SeasideRest and complex structures

...
> A good idea in such discussion to disambiguate the topic is to talk about
RESTful URLs instead of just REST.
>...

I think that RESTfull URLs is appropriate - that is why I gave Ramon Leon's
blog entry.

Thanks, it is good to always learn.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Intrader Intrader

Re: SeasideRest and complex structures

In reply to this post by EstebanLM

I have suggested before Ramon Leon's blog entry
http://onsmalltalk.com/clean-urls-in-seaside as a possible approach to
describing the various 'resources' in your application.
I have looked at another article that allows for AJAX interactions (which you
may want in this case); this article is http://ajaxpatterns.org/Unique_URLs.
The fragment identifiers would describe the 'resources' quite well.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

EstebanLM

Re: SeasideRest and complex structures

In reply to this post by NorbertHartl

Hi,

El 23/04/2011, a las 4:44a.m., Norbert Hartl escribió:

>
> Am 19.04.2011 um 23:02 schrieb Esteban Lorenzano:
>
>> Hi,
>> I now understand how to use SeasideREST, and I'm trying to use it in a real application.
>>
>> What's the problem? well... I want my rest filters to replace a portion of the screen and not all of it. Let's say I have this structure
>>
>> app {
>> menu { option1, option2, option3, etc. }
>> contents: { hereAComponentForEachOption }
>> }
>>
>> yeah, you need to be a little imaginative to understand what I'm trying to describe, but I think is clear: a main "div" with app, and then two divs, one with the menu and other with contents.
>> In my current application, if I press "option1" I can say contents show: option1Component.
>>
>> So... I want to get same result if I do:
>>
>> http://localhost:8080/app/option1
>>
>> any idea how I can proceed?
>>
> Do you want to have a rest handler as a filter of your application that gives additional control or do you want to receive the whole thing via a rest dedicated handler?

I want a rest handler as a filter to allow the application users to do /app/someBookmark and go directly to the right position.
I can use leon approach (already used it a couple of times), and I can use my own hand made construct artifact (already did it a couple of times, too).
But I want to use SeasideRest because I think is the right way to do it. Not Leon's, not mine: One unique positive way to do it :)
And yes... what I want is not a full REST "server", just the RESTful urls thing, but well.. why not use the filter to do that?

Cheers,
Esteban

>
> Norbert
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Intrader Intrader

Re: SeasideRest and complex structures

I don't know how to use a filter in all situations. I think that the solution
should include AJAX and for that use hash symbols for the 'clean resource' name.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside