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:<div> 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.</div>
<div> 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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Julian<br><br><div class="gmail_quote">On Mon, May 14, 2012 at 9:51 AM, Norbert Hartl <span dir="ltr"><<a href="mailto:norbert@hartl.name" target="_blank">norbert@hartl.name</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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: ?<br>
<br>
thanks,<br>
<br>
Norbert<br>
<br>
<br>
Am 13.05.2012 um 14:59 schrieb Norbert Hartl:<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Am 11.05.2012 um 20:49 schrieb Philippe Marschall:<br>
><br>
>> On Fri, May 11, 2012 at 12:14 PM, Norbert Hartl <<a href="mailto:norbert@hartl.name">norbert@hartl.name</a>> wrote:<br>
>>> I'm trying to wrap my head around how to integrate REST style access within a normal seaside application.<br>
>>><br>
>>> Looking at how seaside works there are basically two possible scenarios:<br>
>>><br>
>>> (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<br>
>>> (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<br>
>><br>
>> Right, render loop it's called.<br>
>><br>
>>> 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.<br>
>>><br>
>>> I assembled a bad hack to prove my point. It is probably very stupid but then I'm no seaside expert.<br>
>>><br>
>>> foo<br>
>>> <get><br>
>>> <path: '/foo'><br>
>>> | ctx cookie session url k |<br>
>>> ctx := self requestContext.<br>
>>> cookie := ctx request cookieAt: '_s'.<br>
>>> cookie<br>
>>> ifNotNil: [<br>
>>> session := self handler cache at: cookie value ]<br>
>>> ifNil: [<br>
>>> session := self handler newSession.<br>
>>> self handler register: session.<br>
>>> self handler useCookies ifTrue: [ self handler addCookieForHandler: session to: ctx ].<br>
>>> ctx request setCookies: (ctx request cookies asOrderedCollection add: ctx response cookies first; yourself).<br>
>>> ].<br>
>>> session properties<br>
>>> at: #presenter put: MyOtherComponent new;<br>
>>> yourself.<br>
>>> self next handleFiltered: ctx<br>
>>><br>
>>> For this work I needed to change WARenderLoopMain>>#start from<br>
>>><br>
>>> start<br>
>>> | root |<br>
>>> root := self createRoot.<br>
>>> self session properties at: #presenter put: root.<br>
>>> self prepareRoot: root.<br>
>>> ((self application preferenceAt: #renderPhaseContinuationClass) new) captureAndInvoke<br>
>>><br>
>>> to<br>
>>><br>
>>> start<br>
>>> | root |<br>
>>> root := self session properties at: #presenter ifAbsentPut: [ self createRoot ].<br>
>>> self prepareRoot: root.<br>
>>> ((self application preferenceAt: #renderPhaseContinuationClass) new) captureAndInvoke<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> What do you think?<br>
>><br>
>> Let's see if you understood you right. You want to:<br>
>> - render presenters (they're not really components since you can't<br>
>> #call: and #anser:) without a session, eg. in a rest filter<br>
>> - dynamically start a session & render loop from a component (that<br>
>> you created in a rest filter or similar)<br>
>><br>
> 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).<br>
><br>
> Norbert<br>
><br>
> _______________________________________________<br>
> seaside mailing list<br>
> <a href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a><br>
> <a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" target="_blank">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br>
<br>
_______________________________________________<br>
seaside mailing list<br>
<a href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" target="_blank">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br>
</div></div></blockquote></div><br></div>