From: Matt F. <ma...@da...> - 2004-04-19 19:16:23
|
Ian Bicking wrote: > If you're using Page.sendRedirectAndEnd it won't be a problem -- that > immediately terminates the request. (I think it still calls sleep, > but that's it) Yeah, that's new. We are using it, but it's weirdly inconsistent and changes behavior depending on when it is called. There's been some discussion about it in the list here. I think that the general consensus is that one shouldn't conditionally run sleep; it should probably always fire. For this reason, we actually like our old crufty way better. > Where you write output is really a matter of convention -- you can do > it anywhere, even in sleep. Yes, but for the sake of docs, new users, and such, it would be good to recommend "best practices". If you do output in sleep, does it end up after the </html> bit? > Also note, though, that the awake/respond/sleep sequence is less hard > coded (in CVS) than it was before -- you can override all three with > runTransaction. So another completely separate method could be added > to that sequence. But I also don't think it's so bad to add it to > respond, so long as it happens before writeHTML (but not in lieu of > writeHTML). > Cool. I'll look into that. Don't forget that not all servlets make HTML; I've got some that make images and such. It's more useful to think of respond as "output" (and request as input) for our purposes, I think. After having this and similar discussions on this list over the years, the trouble seems to be in what people think awake is for. One of the strengths of webkit (IMO) is that it can be so low-level; you can use the lifecycle model to do whatever you want, but this leads to a confusion: 1. some people think awake is for nothing; that we should leave it only for webkit's dark magic 2. some people think awake is for setup, but not for application-level logic (ie, database connections, security stuff, etc.) 3. some people think awake is for setup at the low-level, and at the application-level I like number 3. If you think of a servlet as an application logic object (well, it is an object, duh, but bear with me) then it should have certain methods that correspond to certain events. Actions seem to be the way to manage this sort of thing. Once you've done that, you can output, or redirect, which I consider a special-case of output that is only html specific. Number 3 is pretty easy to do by subclassing and keeping careful track of MRO. Another problem is that I don't think you can fire more than one action on one servlet, so they end up being "meta-methods" sometimes, and therefore look more like event handlers. I'm not making much sense, I guess. It's one of those flexibility get's you power, but also get's you confusion things. I agree that putting actions in awake could lead to awkwardness. It seems crufty to have two parallel processes for actions, though... actions and pseudo-actions? :-) |