Lowering the entry barrier for REST style access

To be honest I thought there would be little more discussion on that topic. Now I'm wondering if I could describe at all what I'm after. I really like to have feedback on that even if it states that it is totally stupid to do things I mentioned.

So nobody is using bookmarkable seaside urls or needs to start the whole stuff from an REST interface? Or is anyone happy repeating parsing in initialRequest: ?

thanks,

Norbert


Am 13.05.2012 um 14:59 schrieb Norbert Hartl:

>
> Am 11.05.2012 um 20:49 schrieb Philippe Marschall:
>
>> On Fri, May 11, 2012 at 12:14 PM, Norbert Hartl <[hidden email]> wrote:
>>> I'm trying to wrap my head around how to integrate REST style access within a normal seaside application.
>>>
>>> Looking at how seaside works there are basically two possible scenarios:
>>>
>>> (1) I request a seaside url and have no session information. In this case a session is created and that is the one and only entry to the render-action-phase-cycle. To any callback/link I get my session and callback parameter to proceed in the processing
>>> (2) I request a seaside url carrying session and callback information. There I jump middle in render-action-phase-cycle and turn it once more. I get the next parameters for the new callbacks. Next thing is (2) again
>>
>> Right, render loop it's called.
>>
>>> Let's assume we add a WARestfulFilter to the seaside application and implement a handler /foo. Using cookies it would lead to a situation that I have access to the seaside session (without parameters I mean, of course the parameters can also be present) from within the handler but no callback information. To me it seems that seaside isn't made that way because it assumes there is a single entry point to the application which is also the start of the one and only render-action-phase-cycle (my focus here is two things: session creation, start of action-render-cycle). But the situation is IMHO desirable. I like to share the session between those calls I probably just like to render a different component when invoked through the /foo handler.
>>>
>>> I assembled a bad hack to prove my point. It is probably very stupid but then I'm no seaside expert.
>>>
>>> foo
>>>       <get>
>>>       <path: '/foo'>
>>>       | ctx  cookie session url k |
>>>       ctx := self requestContext.
>>>       cookie := ctx request cookieAt: '_s'.
>>>       cookie
>>>               ifNotNil: [
>>>                       session := self  handler cache at: cookie value ]
>>>               ifNil: [
>>>                       session :=  self handler newSession.
>>>                       self handler register: session.
>>>                       self handler useCookies ifTrue: [ self handler addCookieForHandler: session to: ctx ].
>>>                       ctx request setCookies: (ctx request cookies asOrderedCollection add: ctx response cookies first; yourself).
>>>                        ].
>>>               session properties
>>>                       at: #presenter put: MyOtherComponent new;
>>>                       yourself.
>>>       self next handleFiltered: ctx
>>>
>>> For this work I needed to change WARenderLoopMain>>#start from
>>>
>>> start
>>>       | root |
>>>       root := self createRoot.
>>>       self session properties at: #presenter put: root.
>>>       self prepareRoot: root.
>>>       ((self application preferenceAt: #renderPhaseContinuationClass) new) captureAndInvoke
>>>
>>> to
>>>
>>> start
>>>       | root |
>>>       root := self session properties at: #presenter ifAbsentPut: [ self createRoot ].
>>>       self prepareRoot: root.
>>>       ((self application preferenceAt: #renderPhaseContinuationClass) new) captureAndInvoke
>>>
>>> Basically it is straight forward. If the request handlers methods would be slightly different the creation of a new session would be very easy. The biggest problem is the injection of a newly created session. I did it by forcing the  added response cookie header into the request header. That's for sure no solution. And I'm not quite sure if the setting of the presenter this way is somewhat ok.
>>>
>>> What it really means is that there can be multiple entry points to a session adding callbacks. At the moment I would use it to make a few things more lazily accessible. But the bigger goals would be that it might be easy to add url paths to seaside components without having to do everything in initialRequest: And to the extreme it would open a possibility to add seaside components to plain HTML pages. I did first tests where I have a simple app that only needs the seaside power at certain points in interaction. I have a simple plain HTML page with javascript that uses seaside components for login and for data entry. But data retrieval is done just via rest calls. I mean for the retrieval I wouldn't even need the session information because the information is public and accesible to anyone.
>>>
>>> What do you think?
>>
>> Let's see if you understood you right. You want to:
>> - render presenters (they're not really components since you can't
>> #call: and #anser:) without a session, eg. in a rest filter
>> - dynamically start a session & render loop from a component (that
>> you created in a rest filter or similar)
>>
> Yes, the latter being more important. I think rendering a component isn't that hard. But having more than one entry to a session is (at the moment).
>
> 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