[Twisted-Python] Woven page instances deferring to each other...

Stuart Hungerford stuart.hungerford at anu.edu.au
Wed Oct 8 20:52:38 EDT 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:

    Thanks -- I'll check that out.

 >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

    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!



:: Stuart Hungerford (stuart.hungerford at anu.edu.au)
:: ANU Internet Futures Group

More information about the Twisted-Python mailing list