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

Donovan Preston dp at ulaluma.com
Thu Jul 7 20:27:42 MDT 2005


On Jul 7, 2005, at 6:07 AM, Alberto Trujillo wrote:

> Hello:
> I have been following this example "http://nevowexamples.adytum.us/ 
> childrenhtml/"to know how works the calls to the children with  
> nevow, but still it's not enough clear for me.
>
> I even add a new child in the childFactory and some print command  
> to follow the way of the calls. Here I show you my modifications:
>
>    def childFactory(self, ctx, name):
>        print "NAME = " + name
>        if name in ['1', '2', '3']:
>            return ChildPage(name)
>        elif name == 'one':
>            return OneRoot()
>
>    def locateChild(self, ctx, segments):
>        child, remainingSegments = rend.Page.locateChild(self, ctx,  
> segments)
>        print "CHILD = " + str(child) + " SEGMENT = " + str 
> (remainingSegments)
>        if child:
>            print "IN THE IF"
>            return child, remainingSegments
>
>        return ChildPage('/'.join(segments)), []
>
> My question is why each time that I call to "one" it goes inside  
> "locateChild" wheter "one" is place in "childFactory", here is a  
> trace of my server.

locateChild is the only external API defined by IResource.  
nevow.appserver.NevowSite will always call locateChild. The  
rend.Page.locateChild implementation calls childFactory.

In your example above, your locateChild is called, which calls  
rend.Page.locateChild, which calls your childFactory.

<snip>

> And when I return to the father, who call to childrenRoot class  
> again, and what is favicon.ico?. I show you the results here.

When you return a tuple from locateChild, nevow.appserver.NevowSite  
(which called locateChild) looks to see if the first element of the  
tuple is None. If it is, it renders a 404 page. If not, it looks to  
see if the length of the second element of the tuple (segments) is  
greater than zero. If there are segments left to be processed, it  
calls locateChild on the new child, passing the new segments, until  
all segments have been consumed.

Search the web for information about favicon.ico -- basically it was  
a non-standard addition made by Microsoft Internet Explorer which got  
adopted by Mozilla and FireFox later. Every time a web browser visits  
a web site, it requests the url "/favicon.ico". If the URL is a 404  
it doesn't do anything. If a valid .bmp file is returned, it is  
displayed in the location bar next to the url of the site. It is also  
displayed in the Favorites menu of Internet Explorer, but I don't  
think Mozilla does this.

(The display of this icon in the Favorites menu is why it is called  
favicon.ico, presumably)

> 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)"
>
> 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.

You should rarely, if ever, have to implement locateChild. The  
nevow.rend.Page.locateChild implementation looks for child_* methods  
on the Page object and also calls childFactory if none was found. The  
only reason to implement locateChild is if you wish to consume no URL  
segments or more than one URL segment.

> 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".

There is obviously a need for more permanent communication. The IRC  
channel worked well while the community was small and while the ideas  
were still new and needed discussing. Now that more people are trying  
to learn Nevow, the mailing list, website, and documentation should  
be used more often, to provide a more permanent record of answers to  
common questions.

The docstrings really need work, too.

Donovan




More information about the Twisted-web mailing list