Re: [Webware-discuss] Changing actions

[Ian B. <ia...@co...>]

On Apr 19, 2004, at 2:21 PM, Matt Feifarek wrote:
> 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.

Sleep should always be called.  Hmmm... but that may have changed 
between versions.  Right now there's:

try:
     self.awake(trans)
     self.respond(trans)
finally:
     self.sleep(trans)

I don't think that's always been the way it's been implemented.

>> 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?

Certainly, best practices are called for.  In many ways this is half 
documentation -- functionally it's all pretty freeform how you use your 
servlet; those factorings are just in there as a suggestion.  But we 
should suggest.

>> 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.

Yes.  Page's writeHTML implementation really *does* focus on HTML, in 
that it factors the page into various pieces (head, body, title 
stylesheet, etc).

Another way to do this would be to call writeHTML in defaultAction 
(like we are now), and expect actions to call writeHTML when they are 
done (if they actually want to write HTML).  This actually means less 
changes to code, and more just specifying a certain pattern.  
(preAction and postAction should be no-ops, though.)  I found the view 
part useful as well, but I'm not sure if everyone would use that.  I'd 
find it useful in components, though, and that would require some 
agreement.

> 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.

I use 3 too, though I've sometimes added a "self.setup()" to my 
SitePage, and allowed servlets to override that instead of awake.  It's 
more consistent because it has no trans argument, and I define it so 
that you never have to call the superclass (since I put all the 
abstract stuff in awake()).  But that's kind of a separate detail -- 
but it does separate "framework" setup and "servlet" setup (where I 
think of my SitePage as a mini-framework).

> 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 think I'm losing you here.  IMHO, anything more complicated than 
actions (i.e., specified in a field; one action per request) should be 
coded explicitly.

> 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? :-)
>
--
Ian Bicking | ia...@co... | http://blog.ianbicking.org