[Twisted-web] How to nest LiveElements? (getting a MissingRenderMethod error)

Jean-Paul Calderone exarkun at divmod.com
Fri Dec 1 16:25:19 CST 2006


On Fri, 1 Dec 2006 20:08:39 +0200, kgi <iacovou at gmail.com> wrote:
>On Friday 01 December 2006 17:52, Jean-Paul Calderone wrote:
>
>> The difference between Fragment and Element is just this: Fragment
>> renderers are passed a context, Element renderers are not.
>> [...]
>> The difference in the way render methods are dispatched between Fragment
>> and Element is somewhat incidental to this.  At some future time, it may be
>> possible to customize Element so that it also dispatches to render_, since
>> this isn't really an essential part of the change Element actually exists
>> to facilitate.
>
>OK, so it's not some Deep Architectural Reason; it's just that "Elements are
>not Fragments", and they use a slightly different syntax. Thanks for the
>clarification.
>
>I do have one more question on this subject of LiveElements, if you don't mind
>imparting some more wisdom.

I can try. ;)

>
>When I'm completely stumped by something, I try and grep through the various
>Divmod sources to try and find an idiomatic usage (or even one that
>says, "TODO: We really should fix this one day" :-) ).
>
>One surprising result was that most of the LiveElement-derived classes don't
>generally have a docFactory defined, but rather implement INavigableFragment
>and implement non-GUI 'business logic' (e.g. looking up and storing things in
>a DB), although they do return renderable elements from their renderer
>methods.
>
>An example of this would be the FromAddressConfigFragment class in
>Quotient/xquotient/compose.py
>
>What is the reason behind this approach? My approach has generally been to
>build a bunch of GUI-neutral 'business logic' objects and access these from
>the GUI layer (thereby theoretically allowing the GUI to be changed, blah,
>blah, not that I've ever heard of a successful GUI change, mind.).

There isn't really any strong justification for the way much of that code 
is factored.  It would probably be better if it separated view from model 
more consistently.

>
>I guess one advantage of the approach in the Divmod sources is that you
>minimise "interface duplication": you don't have client-side JS calling
>server-side LiveElement.doStuff(), which has to call
>BusinessObject.doStuff().

But at the cost of making things harder to test and understand. ;)  Ideally
there would be a way to eliminate duplication and keep view and model 
separate.  I don't think we've completely figured out how to do that yet, 
though.

>
>Are there other motives and reasons I've completely failed to think of?
>

As I mentioned, the main reason here is probably just expendiency.  We have 
way too many things to do, and sometimes we cut some corners.

Jean-Paul



More information about the Twisted-web mailing list