Matt Feifarek wrote:
> Ben Parker wrote:
> >awake. My view (I'd love to hear others) is that an unhandled exception
> >in awake() is called a bug and should be fixed in development. I
> don't want
> >the framework to force me to write sleep() with extra
> conditional logic to
> >avoid clobbering an exception raised from a bug I may code into awake().
> And I agree that they should be thought of in pairs; everything that
> awakes must also sleep. In fact, everything must also respond, but it
> can do so by sending a redirect or running an action.
> This has bugged me about WebKit for a while, and we always change our
> SitePage to make it more consistent:
> Our servlets ALWAYS do awake - respond - sleep. WriteHTML() is really
> inside of respond, and is effectively the default "action". Other
> actions cause WriteHTML to not really run, and you get bone-headed
> output like:
> Usually, when an action is run, you either want to redirect somewhere OR
> do some output. Either way, there is still a response. But the output
> chain that is so nice in WK is short-circuited with actions.
> Also, I'm not sure that the action should be called from respond...
> respond should be about sending data to the client. Action is usually
> used to do some application logic, like saving data to a database.
> Sometimes it's an alternate output, I suppose...
> How do most people listening use actions?
> I suppose that rather than keep complaining, I should make a proposal. ;-)
Inside the respond function is a bit more Pythonic - there's a million and
one ways to deal with actions and writing HTML. For some installations,
we've modified _respond in a Page subclass to always call writeHTML after
an action, unless there was a redirect during awake or an action (this
structure is from the pre-"endResponse()" days). So the last few lines
of _respond are something like:
if not transaction.response().hasHeader('Location'):
Sometimes I'll have actions that actually write the HTML to the response,
sometimes I'll have actions that generate HTML and store it in the servlet
until writeHTML() draws it in a particular spot on the page, and
sometimes I'll have actions that just perform data modification and write
no HTML (ie redirect).
But just last month I used an outside contractor to convert some admin
from JSP into Webware servlets. And his first inclination was to require an
_action_ field for every page view, and bypass writeHTML all together.
For example, the EditWidget page may have both "Add new widget" and
"Edit existing widget" modes, and he put all the HTML into action functions,
requiring the page to be requested with either:
Then was would have been the "save" action is handled inside either of
Not my normal approach, but I had never thought of doing it that way before
so I though I'd mention it.