Matt Feifarek wrote: > | See the problem? If SitePage.awake() calls endResponse() then > > Yeah. It seems there's no "sure fire" way to do it. You > either run the risk > of calling it when you shouldn't or not calling it when you > should. It's up > to the servlet author to be rigorous... maybe an exception could be > introduced that says in effect "awake called, but no > corresponding sleep!" > to help you track down bugs introduced.
Hmmm. I just noticed that if an exception happens during respond(), sleep() doesn't get called (unless it's the new EndResponse exception which I just added). Should it? > > | Any other opinions? This code is brand new, so now's the > | best time to get > | it right :-) > > Well, in a way, the most important thing is that response() > is avoided, > since that's where output happens, and it's stupid to do > output if there's a > redirect in the header... but it's also likely that a > well-written servlet > has its 'heavy lifting' in (or from) awake()... database code > or whatever. Why should a well-written servlet do its heavy lifting in awake()? awake() is a bit of a pain to use because of the extra transaction argument. I'm tempted to stop using awake() in my application entirely and just add my own extra preRespond() step. I don't seem to be using sleep() for anything at all, so I wouldn't even need an equivalent to sleep(). > > What we did was to wrap up our response() sorta like this... > > if not self._pendingRedirect: > self.response() > > It works, but it's clearly a hack. > > I like how your method is immediate, but it's somewhat > dangerous because it > throws all the automatic cycle out the window, and leaves > cleanup to the > servlet author. I suppose that's ok, since it's a > /relatively/ esoteric > thing to do. > > This seems related to actions somehow, which also interrupt the normal > awake-respond-sleep cycle somewhat... I've been meaning to > post a little > discussion about actions. Maybe I should get off my butt and do that > tomorrow. Basically, I don't like how actions require a > completely separate > output chain; if you've got a nice template running, you've > got to call > writeBodyParts() by hand to get back to it... I think that > actions should > all be in awake rather than respond. We sorta did that in our > FormKit. It > works well. Output happens the same always, but you > conditionalize parts of > the output... if formSuccessful: blah else: bleah etc. Hmmm. I'm reluctant to change the way actions work in Page because it could break many existing WebKit apps. If it's really that inconvenient, then FormKit could add its own action-like handling, not based on Page's actions. - Geoff ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
