[Twisted-web] How to nest LiveElements? (getting a
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
>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
>An example of this would be the FromAddressConfigFragment class in
>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
>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
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,
>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.
More information about the Twisted-web