Sold. +1
Chris
On Thu, Dec 16, 2010 at 11:57 PM, Mark Ramm <mark.mchristen...@gmail.com>wrote:
> 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.
>
>
--
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.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
