I like actions the way they are - they are very simple to understand.
If you have a hello "Aaron" type app its easy to setup a servlet like
self.write('<form><input type="text" name="username"><submit
self.write('Hello %s' % self.request().value('username','No User Name'))
If you need a more complex action style you can switch to one of the
formKits or move to some MVC type approach.
I vote to leave actions as they are - but provide more robust solutions
for other needs.
Maybe a split page into basePage and ActionPage(basePage) where basePage
provide all of the helper functions in page = except the actions. But
for that matter we could just offer a newPage(page) class taht would
change the way action works.
You can't change actions (IMHO) without chaging the
writeHead-writeBanner-WriteContent-writeFooter style of page. It makes
sence in that context. If you go off and do strange things like Cheetah
or serving images - then maybe having actions just speak up in the
content phase is wrong.
Ian Bicking wrote:
> 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:
> 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
>> 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
>> 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 | ianb@... | http://blog.ianbicking.org
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> Webware-discuss mailing list
"I don't know what's wrong with my television set. I was getting
C-Span and the Home Shopping Network on the same station.
I actually bought a congressman."
- Bruce Baum