[Repoze-dev] [issue122] repoze.who bug in api.py
New submission from Nikolai Sevostjanov nikolai.sevostja...@gmail.com:
Index: repoze/who/api.py
===
--- repoze/who/api.py (revision 8256)
+++ repoze/who/api.py (working copy)
@@ -183,7 +183,7 @@
plugins = match_classification(IChallenger, candidates,
self.classification)
logger and logger.info('challengers matched for '
- 'classification %s: %s' % (classification,
+ 'classification %s: %s' %
(self.classification,
plugins))
for plugin in plugins:
app = plugin.challenge(self.environ, status, app_headers,
--
messages: 353
nosy: asakura
priority: bug
status: unread
title: repoze.who bug in api.py
__
Repoze Bugs b...@bugs.repoze.org
http://bugs.repoze.org/issue122
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue122] repoze.who bug in api.py
System message: -- topic: +repoze.who __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue122 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue122] repoze.who bug in api.py
Tres Seaver tsea...@agendaless.com added the comment: Thank you for the patch. It looks as though we don't have tests for all of the logging stuff. -- assignedto: - tseaver nosy: +tseaver status: unread - chatting __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue122 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue123] chapter 8
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
[Repoze-dev] [issue124] chapter 9
New submission from Will Seaver will.sea...@gmail.com:
My big question for this chapter is: Isn't the way that URL dispatch works much
like a hybrid application to begin with? If a route cannot be found to match a
request, traversal is undertaken, therefore performing all of the functions of a
hybrid application. I can derive that the usefulness comes from the ability have
multiple root objects, which is useful for setting up an authentication policy
(I think? I could be completely turned around), but beyond that I don't see the
point.
p. 97: A *traverse token at the end of the path in a route's configuration
implies a stararg capture value. When it is used, it will match the remainder
of the path segments of the URL. This remainder becomes the path used to perform
traversal. So if the route is /foo/bar/*traverse, and the path_info given is
/foo/bar/1/2/3/ then the path used to perform traversal is /1/2/3/?
definitions needed:
root factory (p. 97: ...repoze.bfg will attempt to use traversal against the
root object implied by the root factory.)
in the example given on p. 97:
root = Traversable(
{'a':Traversable({'b':Traversable({'c':Traversable({})})})}
This is clearly the crux of the Traversable class, the thing that sets
everything into motion, and I can't make heads or tails of it. Explanation?
p. 98: If the URL that matched a route with the path :foo/:bar/*traverse, is
http://example.com/one/two/a/b/c, the traversal path used against the root
object will be a/b/c. As a result, repoze.bfg will attempt to traverse through
the edges a, b, and c, beginning at the root object. What is the root object in
the given example?
Also, the question of the __getitem__ method comes back to haunt me in this
chapter. If I knew how to determine which objects possessed the __getitem__
method, I would be much more equipped to puzzle out the finer points of
traversal.
section 9.3.2: Binding Extra Views Against a Route Configuration that Doesn't
Have a *traverse Element in Its Path
I need a hand with this one.
--
messages: 356
nosy: kwseaver
priority: wish
status: unread
title: chapter 9
topic: bfg book
__
Repoze Bugs b...@bugs.repoze.org
http://bugs.repoze.org/issue124
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue125] chapter 10
New submission from Will Seaver will.sea...@gmail.com: p. 106: A view callable may always return a WebOb Response object directly. It may optionally return another arbitrary non-Response value. such as a render_template_to_response? 10.1.2.: Defining a View Callable as a Class Have I ever used this method of view declaration before? If I had my laptop I could take a look at any number of views.py, but I can't remember whether I had previously defined views callable as classes or instances. p. 108: This style of calling convention is most useful for traversal based applications, where the context object is frequently used within the view callable code itself. is there an easily-found example of this being done? On the subject of renderer factories (p. 115): Why would it be necessary to create a renderer factory? Is this an alternate style of doing things, and because I use Chameleon ZPT as a renderer I won't ever need to know it, or is there value in learning how to construct a renderer factory? p. 120: There is a paragraph explaining the importance of specifying the use of UTF-8 when rendering forms. Why is it important to use UTF-8 as opposed to Unicode or another encoding system? overall, I understood this chapter pretty well, given that I have worked a lot with views callable, and it was one of the more easily-comprehended chapters for me. -- messages: 357 nosy: kwseaver priority: wish status: unread title: chapter 10 topic: bfg book __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue125 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue126] chapter 13
New submission from Will Seaver will.sea...@gmail.com:
p. 153: in the example given:
def sample_view(request):
response = render_template_to_response('templates/foo.pt', foo=1, bar=2)
response.content_type = 'text/plain'
reponse.status_int = 204
return response
Are the response.content_type and response.status_int statements making
assertions about the response, or defining the response?
p. 154: The association of a template as a renderer for a view configuration
makes it possible to replace code with a view callable that handles the
rendering of a template. Is this done within the configure.zcml?
p. 154: The path [to the renderer] can alternately be a resource specification
in the form some.dotted.package_name:relative/path, making it possible to
address template resources which live in another package. can this also be done
in zcml?
section 13.4: Templating with Chameleon Text Templates
Are there any advantages to using .txt files as templates (as opposed to using
.pt), or is this just another equally valid way of doing things?
section 13.6: Automatically Reloading Templates
adding --reload at startup time eliminates the need to change anything inside
the .ini file, right?
--
messages: 358
nosy: kwseaver
priority: wish
status: unread
title: chapter 13
topic: bfg book
__
Repoze Bugs b...@bugs.repoze.org
http://bugs.repoze.org/issue126
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue127] chapter 14
New submission from Will Seaver will.sea...@gmail.com: Root factory gets defined: A root factory returns a model instance. This was very helpful. p. 162: Specifying an interface instead of a class as the context or containment arguments within view configuration statements effectively makes it possible to use a single view callable for more than one class of object. Why is it desirable to use a single view for two different types of models? Why not just write two separate views? p. 163: A model class may implement zero or more interfaces. Under what circumstances would it be necessary for a model class to implement more than one interface? -- messages: 359 nosy: kwseaver priority: wish status: unread title: chapter 14 topic: bfg book __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue127 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue128] chapter 15
New submission from Will Seaver will.sea...@gmail.com: p. 172: ...in applications such as CMS systems where fine-graned access is required on an object-by-object basis. What is CMS? p. 173: For example, the authentication.RepozeWho1AuthenticationPolicy enabled by the repozewho1authenticationpolicy ZCML directive respects group information if you configure it with a callback. What is a callback? p. 174: The ALL_PERMISSIONS object is actually a stand-in object that has a __contains__ method that always returns True, which, for all known authorization policies, has the effect of indicating that a given principal has any permission asked for by the system. This seems to be useful for creating an admin class of user(s). Am I getting this right? 175: Under the ACL following: __acl__ = [ (Allow, 'fred', 'view'), DENY_ALL ] Does this mean that only one person is allowed to view the application, and that all others are forbidden? p. 177: in the sample authtktauthenticationpolicy given: 3. callback=.somemodule.somefunc Is this module representative of a security.py, or perhaps a login.py? or is it representative of another kind of security-related module? p. 178: How does the mere presence of aclauthorizationpolicy/ in a ZCML config file enable an authorization policy? p. 179: An authentication policy the policy that allows or denies... should be is the policy that allows or denies... p. 179: For example, it might be desirable to construct an alternate authorization policy which allows the application to use an authorization mechanism that does not involve ACL objects. What are the circumstances under which such a policy would be desirable? -- messages: 360 nosy: kwseaver priority: wish status: unread title: chapter 15 topic: bfg book __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue128 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue129] chapter 16
New submission from Will Seaver will.sea...@gmail.com: I don't think I understood word one of this chapter. Maybe I could go over it with one of you in person? -- messages: 361 nosy: kwseaver priority: wish status: unread title: chapter 16 topic: bfg book __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue129 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue130] chapter 17
New submission from Will Seaver will.sea...@gmail.com: From what I can tell from this chapter, event subscribers are useful for two things: 1) seeing every time that someone makes a request 2) determining load on the application -- messages: 362 nosy: kwseaver priority: wish status: unread title: chapter 17 topic: bfg book __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue130 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
