If the general consensus is that defaultPostAction() method isn't useful
to the general public, perhaps I should retract my patch (I can just
maintain my local modifications on my own).
On Tue, 2002-10-08 at 23:49, Ian Bicking wrote:
> 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
>
>
--
Jason D. Hildebrand
[EMAIL PROTECTED]
-------------------------------------------------------
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
