[Seaside] Lowering the entry barrier for REST style access

[Julian Fitzell]

I can't tell for sure, but this *sounds* like it's related to work I was
playing with at ESUG last year. There were two parts:
 1) Making session continuations into request handlers. This is implemented
in the 3.1 repository. A new render loop can thus be easily started by
creating a new request handler and delegating to it or registering it in a
dispatcher or registry.
 2) Splitting out the concept of a session (in terms of session data) from
an instance of a render loop. I got part way into this but then ran into a
couple of conceptual questions and a concern that doing it properly would
break backwards compatibility for something that I wasn't sure people
wanted. The idea was that you should be able to have session data pulled up
by a cookie even in REST-style handlers and could create render loops as
needed, which would use that data.

Both of these should be really helpful for creating callbacks for external
APIs, sending emails with links, and so on. Plus, hopefully, the usual
problem of wanting to move from a restful "guest" application to a signed
in application using continuations.

I'm fairly swamped at the moment with school, but am happy to discuss
further if that sounds relevant. Like you, my biggest problem was feeling
like I was writing in a (partial—thanks Nick!) vacuum and not knowing if I
was going in the right direction. Probably best to email (or at least CC)
me directly as I'm not following the list on a day to day basis.

Julian

On Mon, May 14, 2012 at 9:51 AM, Norbert Hartl <norbert at hartl.name> wrote:

> 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 <norbert at hartl.name>
> 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
> > seaside at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20120514/149f251b/attachment-0001.htm