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
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
