[Twisted-web] How to nest LiveElements? (getting a
iacovou at gmail.com
Fri Dec 1 12:08:39 CST 2006
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.
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.).
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
Are there other motives and reasons I've completely failed to think of?
More information about the Twisted-web