[Seaside] Some questions about Seaside architecture

[Lukas Renggli]

>      * How is "blocking component call" implemented? My interpretation
>        of section 8.4 of the article would be that when child component
>        is called, a continuation is taken, and essentially the follwoing
>        code is executed:
>
> childComponent.addOnAnswerEventHandler(continuation)
>          decorator.replaceMe(childComponent)
>        To be more precise, the continuation should be partial,
>        with respect to the start of event handler.

Yes, #call: looks more or less like your suggestion (I put your code
in front of the actual Smalltalk code as comment):

Component>>call: aComponent
	^ AnswerContinuation currentDo: [:cc |
		self show: aComponent onAnswer: cc]

Component>>show: aComponent onAnswer: aBlock
	| delegation event |

	"decorator.replaceMe(childComponent)"
	delegation := WADelegation new delegate: aComponent.
	event := nil.

	"childComponent.addOnAnswerEventHandler(continuation)"
	event := aComponent onAnswer: [:v |
		delegation remove. event remove. aBlock value: v].

	"decorator.replaceMe(childComponent)"
	self addDecoration: delegation.
	WARenderNotification raiseSignal.

>      * If instead of "blocking calls", one would have primitive:
>          callAsync(component, onCompleteEventHandler)
>        how much the design of Seaside framework would change?
>        Would it still use continuations? Or would it suffice
>        to have event handlers (that never block) implemented
>        using closures?

I am not sure what you mean, but I think this is what #show:onAnswer:
(as shown above) already does.

>  * Is it possible to "block" for some events other than "answer".
>    Would it be possible to write something like:
>
>      buttonYes = new Button()
>      buttonNo = new Button()
>
>      eventYes = buttonYes.getOnClickEvent()
>      eventNo = buttonNo.getOnClickEvent()
>
>      event = eventOr (eventYes, eventNo)
>
>      waitEvent(event)
>
>      if (eventYes.hasOccured)
>          message "You pressed Yes!"
>      else
>          message "You pressed No!"

Of course you can do this when 'rendering' the buttons (or anchors,
whatever) ...

	html submitButton
		callback: [ self inform: 'You pressed Yes!' ];
		text: 'Yes'.

	html anchor
		callback: [ self inform: 'You pressed No!' ];
		text: 'No'.

... however an approach using a separate component that answers ...

	(self confirm: 'Yes or no?')
		ifTrue: [ self inform: 'You pressed Yes!' ]
		ifFalse: [ self inform: 'You pressed No!' ].

... gives better reusability of the code.

>  * Back-button suport:
>      * Are continuations essential to back-button support?

Yes, it is essential being able to take a snapshot of the
execution-context if you have a flow of components. Simple
applications that just #call: and #answer: without defining a flow
(multiple conditional/looped calls) might just work  using only #show:
and #answer:.

>      * Is 'registerObjectForBacktracking' essentially equivalent of Java
>        serialization with exception that some objects are omitted?
>        Does it make a shallow or deep copy of registered objects?
>        Does it give substantially better memory footprint in useful
> configurations?
>        ... as compared to copying whole application tree on each request.

You are able to copy whatever you want by overriding #snapshotCopy,
that defaults to #shallowCopy. Copying the whole application-state
doesn't make sense, it is a design decision that has to be made during
the development, see
http://www.lukas-renggli.ch/seaside/advanced/slides/Backtracking.pdf.

>      * How does 'registerObjectForBacktracking' work with garbage
> collection?
>        Weak refereces?

Yes, the default-implementation uses weak-references. At lest
everything will be collected at the session-timeout.

>      * Can one backtrack mutable variables within the closures that
>        are not referenced from components?

Yes.

>      * Are Seaside sessions serializable? Are closures serializable in
> Smalltalk?

No. And it is certainly not easy to do, because a closure might
reference the whole image; however if somebody is willing to invest
time and/or money this could be possible. In Smalltalk one can do
everything ;-)

>      * Would it be feasible to implement copy-on-change saving of snapshots
>        for backtracking?

Yes.

>  * What is Your opinion, whether it would be feasible to implement Java
>    version of Seaside using:
>      http://jakarta.apache.org/commons/sandbox/javaflow/
>    (note that this is weaker than real continuations & call/cc) and not
> using
>    Java threads to imitate continuations like LakeShore does:
>      http://lakeshore.sourceforge.net/usersguide.shtml
>    Or is there some other important language feature missing?

Yes, this is certainly possible, however I wonder if it will ever
reach the the elegance of Smalltalk? Moreover, JavaFlow is not Java
right? As far as I understood it is a JavaScript dialect running
within Java? So why not building a Smalltalk VM inside Java and run
Seaside code within Java? ;-)

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch