Ian Bicking wrote:
>On Tue, 2002-10-08 at 22:39, Matthew J. Feifarek wrote:
>
>
>I myself never use actions, though kind of for this reason -- I have a
>hard time arranging the logic when actions are sometimes called, and
>sometimes not. My solution has been not to use actions at all.
>
>
I like the cleanliness of actions; put the security check up inside of
handleActions() and forget about it; just write methods. It seems more
OO than huge trees of if/elif/else. But I can see your point.
>BTW, I've been using an alternate Page-like servlet structure (which I
>haven't put in CVS or anything -- but maybe I should put it in
>Experimental). Anyway, it makes much more significant use of
>exceptions. I have a feeling it would simplify what you are doing,
>
>
We are doing something similar; catching the exception with a runtime
mixin into the Transaction class. If a user fails to pass security tests
in awake(), we want to short-circuit the rest of awake, so we throw an
exception that's caught by the thing that called awake... Transaction.
It's a little ugly shoe-horning this into Transaction, but it seems to
work without any ill effects.
>since at any point you could raise a Forbidden exception. In general
>I've found that cleaner than doing security through if statements.
>
>
Agreed.
>Do you mean that, if no explicit _action_ was given, you'd do something
>like handleAction('default') (and skip writeHTML entirely, but the
>default action would call writeHTML by default)?
>
>
I'm saying that it essentially IS this way already... as written, if
there are no actions, webkit runs writeContent; this IS the default action.
To pollute matters even further, parts of writeHTML() are still called
when an action is triggered; there are TWO PLACES that these methods are
called; ick. We moved around this in FormKit with a reinterpretation of
preAction --> action --> postAction, but it always bothered me.
Aside from redirects, every servlet is going to output something, so
every servlet is going to have a writeHTML. SO, I'm saying that by
putting application logic into actions, and letting output methods be
called from that application logic, you end up with a simpler lifecycle
setup:
awake()
respond():
handleAction():
preAction():
# write beginning of html page here, including header,
stylesheets, body tag open, etc
action():
# do application logic; writing to database, whatever
# call appropriate output method or if/else the output here
postAction():
# close up the html
sleep()
This seems preferable to "do this when there's an action, and do this
other thing when there isn't". I see the non-action case as a weird
exception to an otherwise solid way to use a web browser to talk to
server objects.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
