[Twisted-web] fragments with child lookup
markus at bluegap.ch
Fri Sep 22 11:47:47 CDT 2006
> Ok but this should be accomplished in a different way IMHO. You should
> have a Fragments container somewhere and lookup stuff in there. It
> doesn't make too much sense to have fragment children IMHO.
Why not? I often have 'sub-templates', like you see in my example, where
the hierarchy for URL 'www.mysite.com/foo/bar.html' would be:
autohandler > foo/autohandler > foo/bar.html
'autohandler' is never going to include 'foo/bar.html' directly. And
both 'autohandler' as well as 'foo/autohandler' should always have a
child to include somewhere.
To clarify the concepts of Pages and Fragments, the top level template
(the 'autohandler') does not exactly look like a 'Fragment' to me, since
it includes all the <html><head .../><body .../><html> tags.
> Well... Pages can be used in place of the Fragments but they will be
> considered as Fragments with no extra functionality (even if the code is
> there) thus it's better to stick with Fragments entirely for this usecase.
Uhm... but I can add render_xy and data_xy to Fragments, can't I?
>> As you can see in my example, I've written my own
>> 'locateFragmentChild()' method which does exactly what I'm describing
> Well but you just need to lookup stuff here and there,
No, I need to look stuff up in the Fragment, then that Fragment again
needs to lookup it's 'child'.
It's not like using a Fragment for the top navigation, one for the
breadcrumbs and one for the content. Although I could do it that way, it
would be confusing, because I would always have to check the URL (or the
segments in nevow). I'd loose the hierarchy information in my code.
> if you need to
> include different fragments in a particular fragment then I guess this
> locateFragmentChild is sort of useful although the name is not the best
> I can think of, simply locateFragment should be enough (but as I can see
> there's really no fixed hiararchy of Fragments and you shouldn't use the
> same mechanism used in locateChild, I'd rather go with a dictionary
> containing all of them because in the end that's what you are actually
> doing, including a fragment depending on the url segment).
Well, I think you got it by now: I just really, really, really want to
arrange my Fragments hierarchically. :-)
>> <snipped my example>
> I don't see a connection between this and the fragments though.
For me these also looks more like Pages. But I can't set
docFactory = ['autohandler', 'foo/autohandler', 'foo/bar.html']
Or would that probably be an alternative? Write a DocFactory which
processes multiple templates, which include their child with a special
content renderer... Or just read all the templates and output one Stan
tree, doing the multiple-template-connecting in the DocFactory?
> Yes, they are a recent addition for a usecase in Quotient. You can pass
> arguments by using closures of course. But inserting renderers is a
> strage usecase, I've never needed it and pre-processors were added to
> change urls on the fly (I think for caching purposes) when loading
> templates, not for changing templates in that hard way. You might find
> some problems in doing that, but I've never tried.
Why should that lead to problems? Seems like a very clever concept to me
(adding renderers or data on the fly with preprocessors).
I'm also changing urls on the fly, the relative ones. If I can pass
arguments to the preprocessor, I can easily get away without adding a
Thank you for your help, I'll have a look at your nevow sources.
More information about the Twisted-web