[Twisted-web] fragments with child lookup

Fri Sep 22 11:47:47 CDT 2006

Hello Valentino,

You wrote:
> 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 
>> above.
> 
> 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 
renderer.

Thank you for your help, I'll have a look at your nevow sources.

Markus