On 01/14/2011 09:09 PM, Alice Bevan–McGregor wrote:
On 2011-01-14 19:53:58 -0800, Mike Orr said:
Hi all, I'm starting an article on Pyramid for Pylons 1 users,
focusing on the differences between the frameworks and how to do
familiar things in Pyramid. It'll also cover add-on stuff like forms
and auth, or at least list the alternatives available.
I'm wondering if there are any particular questions people would like
included. If so, please email them to me.
--
Mike Orr <sluggos...@gmail.com>
Here's a good question for inclusion:
Other than the additional step of resolving the 'view' associated with a
'resource', which seems like a great idea, how does dictionary-based resource
resolution differ from object dispatch?
object dispatch is a turbogears concept, not pylons. while i think a "pyramid
for TG users" guide would be a valuable resource, i think it'd be a bit
confusing to pu such a reference in a "pyramid for pylons users" document.
From what I've seen in blog posts—overriding the dictionary lookup method—it
seems a little too close to object dispatch
too close? too close for what? this sounds a bit pejorative, but i'm not
quite understanding what you're getting at...
where you have straight-up
attribute lookup—allowing override using __getattr__ and usually some
combination of __default__ (effectively __getattr__ with extra arguments) and
__lookup__ (redirecting the dispatch by returning a new object to inspect).
i'm not intimately familiar w/ TG's object dispatch, so i can't really
comprehensively address the differences btn object dispatch and resource
traversal.
in my mind, though, there's a pretty big difference btn URLs being constructed
based on object attributes vs. URLs being constructed by traversing nested
dictionaries. i think of object attributes as primarily a code construct; i
would expect two instances of the same class to have the same attributes, for
instance. generating URL paths via object attributes makes me wary that the
URL structure of my application is going to be tightly coupled with my code
choices, such that refactoring my application would change the URLs in use.
dictionaries, on the other hand, are conceptually just data bags. i have no
expectation that two dictionary-like objects of the same type would contain
the same data, just that they would store that data in a similar fashion. i
could refactor the functionality of those objects to my heart's content, but
as long as the dictionary lookup API still worked, i wouldn't need to worry
about the impact it had on my URL paths.
i can see how the two might seem more similar when you look at some of the
traversal examples in the pyramid docs, since they show trivial
implementations where the dictionary keys and values are hard-coded in python.
in practice, however, this is rarely the case; traversal resources usually
provide dynamic __getitem__ implementations that fetch their contents from
some data source. changing the URL structure of your site might involve a
database migration, but it usually wouldn't involve any code changes.
of course, URL matching is more flexible in this regard than either other
options. change the matching pattern, and the URLs have changed. no muss, no
fuss.
-r
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-devel@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.
