Hi,
Valentino Volonghi aka Dialtone wrote:
> To be honest I've tried reading your first email many times and in
> different days but I've not understood the actual usecase.
Thank you for trying! I'm not a native English speaker, thus sometimes
I'm not very good at explaining.
> Other than that what *IS* a child of a fragment conceptually? A Fragment
> is a Fragment, a reusable element of a page.
Right. I try in nevow terms: I want to write a Page, which dynamically
displays different Fragments depending on the URL. I wanted to use all
the 'locateChild()' mechanism for that, but this seems not possible.
Since Pages are derived from Fragments, I didn't think about using
Fragments in the first place at all. (Of course, I'm 'using' Fragments,
but hidden from me through the Page class, which inherits from Fragments).
As you can see in my example, I've written my own
'locateFragmentChild()' method which does exactly what I'm describing above.
The use case is very simple and (IMHO) common: I have a top top level
template containing all the HTML headers and some common design
elements. Plus the top level navigation. Depending on the URL, different
other templates should be inserted (Fragments?). If you know Mason
(perl) or Myghty (python), I want to migrate from there. They have a
structure like that:
autohandler # the default template which gets
# rendered for every request
dhandler # a default handler, called if no child
# is given in the URL, i.e.:
# www.mysite.com/
foo.html # a normal site available at:
# www.mysite.com/foo.html
# it gets rendered as 'child' of the
# toplevel autohandler, thus it
# inherits it's methods and template.
foo/autohandler # the template for subdir 'foo' on:
# www.mysite.com/foo/*
foo/bar.html # a site in the subdirectory
# www.mysite.com/foo/bar.html
# For this, the toplevel autohandler is
# rendered first, then foo/autohandler
# and then foo/bar.html
This is very usefull when writing 'hierarchical' sites, i.e. where you
can navigate in a tree. What's the best way to do that in nevow?
> Another issue is that it uses the context, we are moving away from it
> and it's highly likely that no new patches/features are accepted if they
> still use or rely completely on the context.
Hm. I don't know if that matters to me.
Something else I'm very thankful about are the 'preprocessors'. It seems
they have (more or less) recently been added. Any chance I can pass them
arguments? Currently I simply insert a renderer in my preprocessor, but
I'm not sure if I can do everything with just inserting renderers (but
probably I can, I'll see).
Thank you.
Markus