[Seaside] Some questions about Seaside architecture
Lukas Renggli
renggli at gmail.com
Mon Dec 12 23:11:05 CET 2005
> * 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
More information about the Seaside
mailing list