Hi,
While working my way through the Seaside internals I came across: WAPresenter>>processCallbackStream: aCallbackStream aCallbackStream processCallbacksWithOwner: self. self processChildCallbacks: aCallbackStream. aCallbackStream processCallbacksWithOwner: self Is their a reason for calling #processCallbacksWithOwner: twice? Thanks -- Edward Stow _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> While working my way through the Seaside internals I came across:
> > WAPresenter>>processCallbackStream: aCallbackStream > aCallbackStream processCallbacksWithOwner: self. > self processChildCallbacks: aCallbackStream. > aCallbackStream processCallbacksWithOwner: self > > Is their a reason for calling #processCallbacksWithOwner: twice? Seaside evaluates all callbacks in the context of the component that rendered the callback. There might be callbacks that appear before the child-callbacks, as well as after the child callbacks (before and after refers to the location in the XHTML output). There might be also callbacks that appear in-between the child-callbacks. This case will be handled in the loop of WARenderContinuation>>processCallbacks:. This is all quite complicated and causes some troubles, especially in the context of AJAX. It might be dropped in upcoming versions of Seaside. The price would be that we would need to find other ways to implement (or drop) WABasicAuthentication, WASessionProtector and WATransaction. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On Mon, Apr 14, 2008 at 3:53 PM, Lukas Renggli <[hidden email]> wrote:
> It might be dropped in upcoming versions of Seaside. The price would > be that we would need to find other ways to implement (or drop) > WABasicAuthentication, WASessionProtector and WATransaction. This would be my vote. Avi _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
"Avi Bryant" <[hidden email]> wrote in message
news:[hidden email]... > On Mon, Apr 14, 2008 at 3:53 PM, Lukas Renggli <[hidden email]> wrote: > >> It might be dropped in upcoming versions of Seaside. The price would >> be that we would need to find other ways to implement (or drop) >> WABasicAuthentication, WASessionProtector and WATransaction. > > This would be my vote. > > Avi +1 Sophie _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Lukas Renggli
"Lukas Renggli" <[hidden email]> wrote in message
> Seaside evaluates all callbacks in the context of the component that > rendered the callback. There might be callbacks that appear before the > child-callbacks, as well as after the child callbacks (before and > after refers to the location in the XHTML output). > > There might be also callbacks that appear in-between the > child-callbacks. This case will be handled in the loop of > WARenderContinuation>>processCallbacks:. This is all quite complicated > and causes some troubles, especially in the context of AJAX. > > It might be dropped in upcoming versions of Seaside. Any idea yet which way Seaside 2.9 will go on this? And whether Ajax callback of one component can re-render other distant components without problems? Thanks - Sophie _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> > It might be dropped in upcoming versions of Seaside.
> > Any idea yet which way Seaside 2.9 will go on this? We can't just drop WABasicAuthentication, WASessionProtector and WATransaction, these are not marked as deprecated in Seaside 2.8. Around the time of Seaside 2.2 sessions were able to take decorations. If we reintroduced that, we could move WABasicAuthentication, WASessionProtector and WATransaction to the session without loosing any functionality. Logically these decorations belong closer to the sessions than components anyway. Even if this introduces a significant amount of code-duplication (the whole decoration mechanism) between WASession and WAComponent this is certainly a good way to go. > And whether Ajax > callback of one component can re-render other distant components without > problems? If dropped, that will be a positive consequence, yes. It is certainly a goal to make AJAX easier in future versions of Seaside. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
"Lukas Renggli" <[hidden email]> wrote in message
> We can't just drop WABasicAuthentication, WASessionProtector and > WATransaction, these are not marked as deprecated in Seaside 2.8. Ah, OK. The session option might make sense. >> And whether Ajax >> callback of one component can re-render other distant components without >> problems? > > If dropped, that will be a positive consequence, yes. It is certainly > a goal to make AJAX easier in future versions of Seaside. If possible, please post if/when you know whether 2.9 will (or will not) have some solution to this. Thanks - Sophie _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |