| 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?
Really not sure. I don't really understand the deep magic of the application
server. Can it hang threads if awake() is called but sleep() never? I don't
really understand how important the symmetry is, but I always have tried to
make sure to keep it "by the book" just in case.
When do things like re-pickling the session object happen? That's the kind
of housekeeping that I'm afraid could get short circuited, and it would be a
b*tch to identify and debug.
| 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().
I don't know, really. Maybe I shouldn't have said it _quite_ that way. Here,
we try to have everything that "builds state" happen in awake, so by the
time we get to output stuff, we're all ready to go. There's no technical
reason, I suppose, but it's nice to know that if you've made it to respond,
all your state is fine.
Basically, I see the structure of MY servlets like this:
get_ready (awake):
0. let the superclass wake up
1. collect input vars from fields() or wherever
2. derive any important flags/switches
3. collect required resources (like database records)
4. massage any data or vars, as required for output
output (respond):
1. puke content into the page with various writeXXX methods
clean_up (sleep):
1. identify any housekeeping that needs to be done (store things in
session, etc.)
2. kick back control to the superclass
There's no technical reason why ALL of this couldn't happen inside of
writeTitle(), really. It's a matter of practice for us. It became really
important when we were doing form processing, and it was important to
check/validate all the form fields BEFORE we started writing out the form,
so we could throw little red flags or whatever.
| 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.
I agree. In fact, we didn't "change" anything meaningful. If you look at one
of the pages in our docs:
http://dalchemy.com/python/formkit/architecture.html and look at the second
diagram, you can see what we did. It's pretty well integrated into the
standard webkit model, which is a beef we had with FunFormKit's integration
(no offense, Ian, your code was certainly the inspiration).
I might even go so far as to say that "respond()/writeHTML" is actually an
action, and it's just the default action. "deleteRecord()" is another sort
of action. I like the way that actions are a sort-of event model for the
servlet... you define a new event, find a way to trigger it from the
browser/url, and you write a method that handles that event.
We expanded this idea with some good security controls, so actions have
different classes of security (readonly, read/write, etc). An action has to
be in self.actions() and also self.writeActions() to be able to write. It
wraps the "event model" in security checks in a nice way.
Anyway, I'm rambling.
-------------------------------------------------------
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
