[Twisted-web] how are solving the calls to the children in nevow?

[Kieran Holland]

> Only locateChild(self, context, segments) is part of the IResource API.
> All the child_ and childFactory support is provided by the
> rend.ChildLookupMixin class that rend.Page subclasses.
> 
> What's happening in the above code is that you have an overridden
> locateChild method that calls rend.Page.locateChild.
> rend.Page.locateChild does the child_ and childFactory magic and calls
> your childFactory method. Your childFactory prints the NAME and returns
> the child resource back to your locateChild method which then also
> prints it out as CHILD.
> 
> >
> > 2005/07/07 13:52 IST [HTTPChannel,0,127.0.0.1] NAME = one
> > 2005/07/07 13:52 IST [HTTPChannel,0,127.0.0.1] CHILD = <one.OneRoot
> > object at 0x40701eac> SEGMENT = ()
> > 2005/07/07 13:52 IST [HTTPChannel,0,127.0.0.1] IN THE IF
> > 2005/07/07 13:52 IST [HTTPChannel,0,127.0.0.1] 127.0.0.1 - -
> > [07/Jul/2005:12:52:11 +0000] "GET /one?id=1 HTTP/1.1" 200 47
> > "http://localhost:8080/" "Mozilla/5.0 (X11; U; Linux i686; en-US;
> > rv:1.7.8) Gecko/20050517 Firefox/1.0.4 (Debian package 1.0.4-2)"
> > 2005/07/07 13:52 IST [HTTPChannel,0,127.0.0.1] NAME = favicon.ico
> > 2005/07/07 13:52 IST [HTTPChannel,0,127.0.0.1] CHILD = None SEGMENT = ()
> > 2005/07/07 13:52 IST [HTTPChannel,0,127.0.0.1] 127.0.0.1 - -
> > [07/Jul/2005:12:52:11 +0000] "GET /favicon.ico HTTP/1.1" 200 684 "-"
> > "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050517
> > Firefox/1.0.4 (Debian package 1.0.4-2)
> >
> > And when I return to the father, who call to childrenRoot class again,
> > and what is favicon.ico?. I show you the results here.
> >
> > 2005/07/07 13:58 IST [HTTPChannel,1,127.0.0.1] NAME = favicon.ico
> > 2005/07/07 13:58 IST [HTTPChannel,1,127.0.0.1] CHILD = None SEGMENT = ()
> > 2005/07/07 13:58 IST [HTTPChannel,1,127.0.0.1] 127.0.0.1 - -
> > [07/Jul/2005:12:58:34 +0000] "GET /favicon.ico HTTP/1.1" 200 684 "-"
> > "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050517
> > Firefox/1.0.4 (Debian package 1.0.4-2)"
> 
> favicon.ico is something the browsers request. It's the annoying little
> icon browsers add to tabs and bookmarks. I hate it. See
> <http://en.wikipedia.org/wiki/Favicon>.
> 
> >
> > I would like to know as well if I must to implement all these methods
> > each time that I'm working with children, and what is segments.
> 
> segments is simply a tuple of the remaining URI path segments.
> 
> A URL of http://localhost/foo/bar has segments ('foo', 'bar'). Nevow
> tries to turn those segments into child resources until there are no
> more segments left. A typical sequence of events for that URL might be:
> 
> 1. Nevow asks the root resource to turn 'foo' into a resource. The root
> resource returns a foo resource.
> 2. Nevow asks the foo resource to turn 'bar' into a resource. The foo
> resource returns a bar resource.
> 3. Nevow seems that there are all segments have been used and asks the
> bar resource to render itself.
> 
> However, as you will see below the root resource could consume both
> 'foo' and 'bar' and return a bar resource directly.
> 
> 
> How you choose to traverse the URI depends on what you know and need to
> do ...
> 
> If you know the name of a child resource at development time and the
> child resource never changes then use a child_ class attribute:
> 
>     class Page(rend.Page):
>         child_css = static.File('/path/to/css')
> 
> If you know the name of a child but you need to create it in a special
> way use a child_ method:
> 
>     class Page(rend.Page):
>         def child_time(self, ctx):
>             return TimePage(time.now())
> 
> If you don't know the name of the resource, i.e. it's a database id or
> something similar, then use childFactory:
> 
>     class Page(rend.Page):
>         def childFactory(self, ctx, name):
>             obj = db.getObj(int(name))
>             return ChildPage(obj)
> 
> Finally, if you want absolute control, i.e. to consume two URI segments
> in one go, then override locateChild:
> 
>     class Page(rend.Page):
>        def locateChild(self, ctx, segments):
>           if segments[:2] == ('foo', 'bar'):
>              return BarPage(), segments[2:]
>           return rend.Page(self, ctx, segments)
> 
> Note how that example compares the first 2 segments and consumes both
> 'foo' and 'bar' by returning a new BarPage child and the remaining
> segments - segments[2:]. Only locateChild is able to process more than
> one segment at a time.
> 
> Personally, I nearly always use child_ and childFactory. I only using
> locateChild for more comlpex URL traversal problems.
> 
> >
> > Sorry I know that are a lot of question, but I don't have access to
> > the IRC channel and I couldn't understand the information in
> > "inevow.IReource".
> 
> Hope this explains it well enough now.
> 
> Cheers, Matt

Nice case point demonstrating what I was getting at in the appendix of
my introduction to Stan.  Had that been said in IRC (as I am sure it
has been, many times) then it would be lost and gone forever - here it
is Googlable and provides most of what one would need to write a good
overview of URL traversal ;)

It lead me to wonder further about IRC.  Imagine if python development
was discussed in #python.dev...actually, don't, it hurts.  So what are
the appeals of IRC?

It is instantaneous.  Yes, but often the time saving is an illusion. 
The same problems occur over and over again, even for the same person,
who forgot the answer they got last time...

It can be exclusive.  But the twisted.web developers don't seem like
an exclusive bunch - quite the opposite, on the whole.

It is social.  It is true that IRC feels more like a conversation, and
sarcasm is a little more apparent, but on the other hand you tend to
miss out on the more considered quips... I certainly don't think that
a mailing list precludes development from being a social activity.

It is forgotten.  You can say what you like and it will tend not to
haunt you down the line.  Well, this is a plus for those, such as
myself, prone to putting their foot in their mouth ;)

Pastebins may be Cool, but isn't it actually easier to just "paste"
into an email?  Valuable code fragments should not be consigned to a
bin!

It seems to me that IRC is fine for a developer-only piece of
software, where everyone who uses it hangs out there, but it becomes
counter-productive if you want to extend the user base.  Isn't that
what we all want for Nevow?

I would be interested to hear other people's thoughts on this.

Kieran