[Twisted-Python] Woven page instances deferring to each other...
Stuart Hungerford
stuart.hungerford at anu.edu.au
Wed Oct 8 18:52:38 MDT 2003
Quoth twisted-python-request at twistedmatrix.com:
>On Wed, Oct 08, 2003, Stuart Hungerford wrote:
>> In another Woven page the application can detect these
>> "error" states and I would like to optionally "defer" the HTML
>> generation to the existing error pages:
>
>I *think* here you mean "I'd like totally different HTML generated if
>there is an error state", rather than "my check for the error returns a
>Deferred object". Let me know if I'm wrong.
Quite right -- I did mean "totally different HTML", it was a poor
choice of terms after too little thought ;-)
>Assuming you meant "I'd like totally different HTML generated if
>there is an error state" you probably do want macros or something like
>them. The best documentation I've seen on this is here:
>http://twistedmatrix.com/pipermail/twisted-python/2003-June/004662.html
Thanks -- I'll check that out.
>Followup...
>
>A nicer solution may be to have the parent Page (by this I mean
>http://example.com/bob/ is a parent and http://example.com/bob/result/
>is a child -- parents in the URL structure) do the check and return an
>object of a different Page class, something like:
>
>class MyParentPage(page.Page):
>
> def getDynamicChild(self, name, request):
>
> if error_condition_1:
> return ErrorPage1()
> elif error_condition_2:
> return ErrorPage2()
> else:
> return NormalChildPage()
>
>If there's any way you can determine if the error has happened before
>the child page starts rendering, then I suspect it would be nicer to do
>the error check at child creation time, rather than when the child
>renders.
I can see the sense in this approach, but it does have the effect
pushing implementation of business rules from the wvupdate_foo()
functions into creation time checks. Although, that may be a good
thing, I haven't really got a feel yet for what constitutes "good"
Twisted or Woven idioms.
>[...]
>Since woven renders the entire page before it calls request.write, any
>portion of the view rendering code which detects an error is able to
>call request.redirect (because we can still set headers since we
>haven't written any of the body yet). Just thought I'd chuck that out
>there, it may be totally irrelevant.
This could also be very useful, as Mary points out, it gives us a
choice of where the application logic can be based.
Many thanks to all for the help!
Cheers,
Stu
--
:: Stuart Hungerford (stuart.hungerford at anu.edu.au)
:: ANU Internet Futures Group
More information about the Twisted-Python
mailing list