[Seaside-dev] Issue 100 in seaside: Rethink rendering and responing methods in WASession

[codesite-noreply at google.com]

Issue 100: Rethink rendering and responing methods in WASession
http://code.google.com/p/seaside/issues/detail?id=100

Comment #2 by jfitzell:
Looking at the 'responding' category:

#respond:onAnswer: needs to stay as far as I can see because it needs to  
store the
continuation in the Session's cache. This is a *very* confusing name,  
though, since
"answer" has a specific meaning in seaside and the first parameter sounds  
like it
should be a response. Even just #respond:continuation: would be clearer  
(and maybe
the first parameter should accept either a WAResponse or a block?).

#respond: depends on #respond:onAnswer: and so needs to stay.

#closePopup, #closePopupAndContinue, and #closePopupWithoutReloadingOpener  
depend on
#respond: and so can't really go onto the RequestContext. That said,  
they're kind of
ugly... we could just deprecate them entirely. Or... other thoughts?

#pageIntentionallyLeftBlank, at very least is a cheezy name.  
#returnEmptyResponse or
something would be more correct and could be implemented on the  
RequestContext
instead (there's nothing session-specific about it). It seems a bit  
pointless to add
there though, since we could just deprecate it and encourage users to use
#returnResponse: with "WARespone new"; I'm not sure how important a  
convenience
method it is. We could alternatively use the ResponseFactory to generate  
an "empty
response", which would allow such a response to be customized  
per-application if
desired. Either the session or application would then need to get the  
response and
pass it to #returnResponse:

#newSessionUrl is a bit pointless since the Application's #baseUrl should  
already
include any overridden hostname values. A "new session" is exactly the same
conceptually as simply entering the Application with no parameters, which  
is exactly
what "self application baseUrl" should be providing. I think we should just  
deprecate
this method and remove it.

All the methods in the 'redirecting' category depend on either the  
ResponseFactory or
the #respond: method and so can't really go anywhere else (well, they could  
all move
to WAApplication if desired but I don't think that's any better).

I don't see any "rendering" methods, so I assume you meant the redirecting  
ones?

The "expiring" methods may need to go, but that's covered by Issue 176. I  
also don't
like the "script" methods, but they're referenced by Issue 111.

Everything else looks pretty sane... WASession is looking pretty lean now.





-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings