On Tue, 2002-10-08 at 23:05, Matthew J. Feifarek wrote:
> 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.
But how is putting the code in handleActions different from putting it
in writeContent or awake?
> >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.
My solution was to stop using awake/sleep, and to put a
setup/writeHTML/teardown sequence in respond. Then respond (in your new
Page) catches all the exceptions. No hacking about, and has the same
effect.
> >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.
I agree on the problem, but I don't think this is the complete
solution. For instance, my titles and such are often based on the
content, which is based on an ad hoc action. So I deal with everything
in awake (well, setup), and then everything else is rendering logic.
When it's just rendering logic, it's not as burdensome.
But that's not sufficient either. As I've tried to deal with errors,
the errors will imply their own text (but not always standard text).
And that text should be styled in a certain way, and that style is not
completely contained in the interior of the page (as always, the title
in the head is dynamic, though there are other instances). I haven't
decided how to deal with that -- I'm thinking forwarding is the right
answer, though in the past I've disliked the idea of forwarding.
I dunno... this is kind of scattered, but I feel like the problems fit
together, and the best solution will answer several at once. I'm also
thinking in terms of a replacement for Page that doesn't try to be
backward compatible (or, rather, an alternative to Page).
Ian
-------------------------------------------------------
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
