[Repoze-dev] [issue123] chapter 8

2010-03-08 Thread Chris McDonough

Chris McDonough chr...@plope.com added the comment:

Wiggy also notes that the ZCML tag documentation in this chapter may be 
overkill and that maybe 
it should just defer to the ZCML reference.

--
status: unread - chatting

__
Repoze Bugs b...@bugs.repoze.org
http://bugs.repoze.org/issue123
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev


[Repoze-dev] [issue123] chapter 8

2010-02-26 Thread Will Seaver

New submission from Will Seaver will.sea...@gmail.com:

The first thing I gleaned from the chapter on URL dispatch was that, as opposed
to traversal, URL dispatch works best with sites that can be mapped easily and
concretely, sites with rigid hierarchies, where things are easily divided into
one of several types and there isn't anything left over. However, this
impression seems to be contradicted by the following sentence, from p. 73:
...it often makes a lot of sense to use URL dispatch instead of traversal in an
application that has no natural data hierarchy. So... maybe I've got this
backwards. Not too sure.

One note I have is that perhaps views callable could be defined earlier in the
book, perhaps in the chapter on traversal? I'm not sure why they don't get
defined until just now, but I suppose that's the way it makes sense to most
people, and I know what a view callable is at any rate, so I guess it doesn't
particularly matter.

as pertains to Route Path Pattern Syntax, section 8.2.4: how does the route
:foo/bar/baz make any sense? I would think that the first URL segment would be
much more important toward determining the type of view associated with the
given url than the rest of the segments. abc/bar/baz and dam/bar/baz seem like
they would be two entirely unrelated URLS, but apparently the same view callable
can be assigned to both of them? this confused me greatly.

p. 77: ...may either be a literal string (e.g. foo) or it may segment
replacement marker typo?

Also, does the length of dynamic segments matter? If the dynamic segment :bar is
given, can :bar be replaced with a Unicode string of any length?

p.78: ...when a *stararg remainder match is matched, the value put into the
matchdict is turned into a tuple of path segments representing the remainder of
the path. Is this the same thing as the subpath?

p. 79: The order that routes declarations are evaluated is the order in which
they are added to the application at startup time. This is unlike traversal,
which depends on emergent behavior which happens as a result of traversing a
graph. What is meant here by emergent behavior?

p. 79: The order that route are evaluated... routes

p. 79: In such a configuration, the members/abc pattern would never be matched;
this is because the match ordering will always match members/:def first; the
route configuration with members/abc will never be evaluated. Should literal
segments always be listed before dynamic ones?

p. 79: When that route [one that mentions a factory] matches a request, and a
factory is attached to a route, the root factory passed at startup time to the
Configurator is ignored; instead the factory associated with the route is used
to generate a root object. Why would one have more than one type of root?

p. 83: The main purpose of route configuration is to match (nor not match)... 
huh?

So from what I can tell, the point of URL dispatch is to try to make things more
regimented and cut down on work for the view lookup subsystem etc. However, if
there is no route found, the system falls back to traversal. So why not just use
traversal every time?

p. 87: In fact, the spelling which names a view attribute is just syntactic
sugar for the more verbose spelling which contains separate view and route
registrations. Why have separate view and route registrations?

section 8.6: Is the process of generating route URLs the same as doing URL
dispatch but in reverse?

section 8.7: this whole section makes sense to me somewhat intuitively, but the
actual nuts-and-bolts functioning of it does not. Does PATH_INFO contain a
no_slash or has_slash value in every request?

section 8.8: what are the circumstances under which cleanup after a request is
desirable?

p. 91: looking at the section on setting up ACL within a model class,
specifically relating to the example given:

article = matchdict.get('article', None)
if article == '1':
   self.__acl__ = [Allow, 'editor', 'view']

does this mean that the URL being targeted is /article/1? Does this imply that
there is only one article that requires an ACL? or am I entirely misreading
this, and the '1' represents 'true'?

--
messages: 355
nosy: kwseaver
priority: wish
status: unread
title: chapter 8
topic: bfg book

__
Repoze Bugs b...@bugs.repoze.org
http://bugs.repoze.org/issue123
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev