So, I will confess to being the one who asked for this change, and
while I'm definitely open to other options, I think resource is a good
term for items in the graph. The graph itself I'm not sure what to
call, but I think model is confusing because it is too easy to confuse
with a "domain model" or ORM model.
The overloading problem should be taken seriously because most folks
coming to Pyramid from other python web frameworks, including
TurboGears, Pylons, Django, and most of the "newish" frameworks will
have very different ideas of how the "model" works and will
immediately get confused. And that's a terrible way to attract new
users ;)
But it's worse than just overloading -- I think "model" is confusing,
as is "context" specifically because those terms aren't descriptive
of what's happening.
The main reason behind me asking Chris about this is that I can
imagine writing a simple explanation of the "traversal" model which
makes sense to a variety of TG, Zope, and even Django users.
It would go something like this:
Pyramid dispatch is based on a two phase system.
The first phase is called Resource Location, and in it we use the URL
(Universal Resource Locator) to find a resource. This is done by
taking items from the path, and looking them up in a set of nested
dictionaries called the ResourceTree. You can think of this as
looking up files and directories in a file system. You just walk
down the path elements until you get a file. That becomes the
"resource" that we then publish.
Which, naturally brings us to the second phase which we call "Resource
Publication" uses additional information about the request (request
method, etc) and the resource to lookup a view callable, and call it,
passing in the resource we just found.
There are two big advantages to this:
1) Marketing wise, REST proponents would feel like this framework is a
natural fit for them
2) Reduced learning curve, since folks already know what looking up
files in a filesystem is and how that maps to URL's.
There are down sides, which chris and many of you have raised, but I
think we have to do something, because the current terminology is just
a bit too arcane.
--Mark Ramm
On Thu, Dec 16, 2010 at 9:05 PM, Chris McDonough<chr...@plope.com> wrote:
While it seems people generally agree that some change is required here,
it also seems there are a good number of people who don't like
"resource". Here are the arguments against it:
- we're just switching one overloaded term ("model") for another
("resource"). Zope people tend to think of static files when they
think of "resource", Pylons folks already have confusion about
"resource" due to map.resource and other usages.
- Only the entire url represents a resource. Because
http://example.com/foo/bar is a valid resource does not mean that
http://example.com/foo is. Implying each segment is a resource would
be confusing.
Alternate suggestions:
- "traversal model"
- "node"
- "atom"
- "entity"
- "location"
- Some derivation of "sitemap"
OTOH, none of the alternatives really seem all that attractive to me.
The ones that have practical issues:
- "traversal model" is awful hard to put into APIs.
- "location".. this one is subtle.. traversal nodes
don't actually need to be "locatable" for traversal,
just for the APIs that construct paths and URLs from
them like model_url and model_path (IOW, the concept
of "location" only matters on the way "up" the graph
from a deep node, not downwards during traversal..
neither __name__ nor __parent__ is used during traversal
itself).
The ones I don't like because they're meaningless:
- "atom"
- "entity"
- "node"
The meaningless ones above aren't disqualified because they're
meaningless, though. I would just rather have something with some sort
of meaning.
This is why I'd actually still much prefer "resource" despite the chorus
of objections. Here's a list of objections and responses.
Objection
----------
- Only the entire url represents a resource. Because
http://example.com/foo/bar is a valid resource does not mean that
http://example.com/foo is. Implying each segment is a resource would
be confusing.
Response
--------
I'm not sure this is true. Yes, a particular URL will identify a
representation of a particular resource. But if you use traversal, each
of the nodes in the graph is a potential "resource" and can be accessed
potentially via some URL. The graph node exists to be traversed via the
path_info portion of a URL and, if your application uses traversal,
because of the way traversal works, the fact it exists means it indeed
will "have" a URL. Whether that URL returns some meaningful
representation or not doesn't really seem to be an issue. It doesn't
really seem to be that far away from some more common webby definition
of "resource" (I'm not even sure Roy Fielding would have a problem with
it ;-) ).
Please tell me how this is wrong.
Objection
---------
We're just switching one overloaded term ("model") for another
("resource"). Zope people tend to think of static files when they think
of "resource", Pylons folks already have confusion about "resource" due
to map.resource and other usages.
Response
--------
I'm apt to call this one a wash. Zope people can probably get over it.
Existing BFG/Pyramid users who also conflate "resource" with "static
file" can also probably get over it. I can't speak for Pylons or other
non-Zope folks, but other than the issues Mike raised (map.resource and
other Pylonsish usages of resource), it didn't seem like many non-Zopers
had an issue with it. And since Pyramid isn't really Pylons, and
because we're likely to implement "rest controllers" differently, I
think we can eliminate at least one competing Pylons definition there..
BTW, Restish (http://ish.io/embedded/restish/) also uses "resource" to
define nodes in its graph, although its graph is composed of cooperating
functions:
http://ish.io/embedded/restish/resources.html#so-what-is-a-resource
Fire away,
- C
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-de...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com<pylons-devel%2bunsubscr...@googlegroups.com>
.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-de...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com<pylons-devel%2bunsubscr...@googlegroups.com>
.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
