Re: pyramid terminology: model-resource
Hello, On Fri, Dec 17, 2010 at 7:57 AM, Mark Ramm mark.mchristen...@gmail.com wrote: I think resource is a good term for items in the graph. Why you think resources are need to be bound to locations in graph? I think it's better to think that graph consist of locations and each location has associated resource. For example one can make one resource available via different URLs (read locations) with different views. -- Andrey Popp phone: +7 911 740 24 91 e-mail: 8may...@gmail.com -- 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.
Re: pyramid terminology: model-resource
On Dec 17, 5:57 pm, Mark Ramm mark.mchristen...@gmail.com wrote: 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. Thanks Mark, that made a lot of sense. And I think I understand Traversal now too :) I didn't really have a strong opinion about this topic until now - most arguments for and against kinda went over my head. With that explanation I think Resource is a good choice. -- Cheers Anton -- 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.
Re: pyramid terminology: model-resource
On Thu, Dec 16, 2010 at 11:57:42PM -0500, Mark Ramm wrote: 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. This is a nice explanation. Marius Gedminas -- But perhaps ISO's central secretariat follows just the common industry practice pioneered by Microsoft: We will get it right in the third release. -- Markus Kuhn on ISO 10646 PDF CD-ROM edition signature.asc Description: Digital signature
Re: pyramid terminology: model-resource
On Fri, Dec 17, 2010 at 3:51 AM, Andrey Popp 8may...@gmail.com wrote: Hello, On Fri, Dec 17, 2010 at 7:57 AM, Mark Ramm mark.mchristen...@gmail.com wrote: I think resource is a good term for items in the graph. Why you think resources are need to be bound to locations in graph? I think it's better to think that graph consist of locations and each location has associated resource. For example one can make one resource available via different URLs (read locations) with different views. Well, I actually don't think that's a problem for me, because I separate the domain model from the Resource Tree and therefore can have several resources related to the same data, not to mention that there's still resource publication. But that's a much more complicated set of topics, which I fully intend to try to explore later. I know that view lookup can use portions of the URL as well, which is fine. I'm not suggesting that we remove that flexibility from the system, just that we talk about it slightly differently. --Mark Ramm -- 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.
Re: pyramid terminology: model-resource
Sold. +1 Chris On Thu, Dec 16, 2010 at 11:57 PM, Mark Ramm mark.mchristen...@gmail.comwrote: 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
Re: pyramid terminology: model-resource
Me too. Of course, when something makes sense to me (e.g. XSLT) it is usual a sign of impending doom. --Paul On 12/17/10 9:05 AM, Chris Rossi wrote: Sold. +1 Chris On Thu, Dec 16, 2010 at 11:57 PM, Mark Rammmark.mchristen...@gmail.comwrote: 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 McDonoughchr...@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
Re: pyramid terminology: model-resource
On Dec 17, 6:16 am, blaflamme blaise.lafla...@gmail.com wrote: +1 for your wording Mark additional +1 I recently experienced the pain of having to explain traversal and why it was so cool and necessary for the app we are building. It was very much like showing a dog a card trick. -- 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.
Re: pyramid terminology: model-resource
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17 Dec 2010, at 04:57, Mark Ramm wrote: I think resource is a good term for items in the graph As did Tim Berners-Lee when he coined the referents URI and URL. Note that a URI is still termed a resource even if it does not have a corresponding resolvable URL. Also, the R in URI/URL is the central concept in RDF (Resource Description Framework). Where Pyramid's bfg heritage brings it a directed acyclic graph for a model, RDF uses a directed labelled (hence acyclic) graph for modelling. In the context of the web, the prior claims on resource have a far more cogent semantics than any prior claims on model might have and I fear that there'd be a horrible resource train wreck ahead for Pyramid. I think it is futile to strive after terminological precision in this area. Given that the core of the problem is an anticipated confusion over the semantics of model, I'll include this fragment of a discussion of MVC that I found rather useful: ... the Model-View-Controller pattern had the primary design motivation of separating presentation from domain concerns. The division between the input and output of the application (which resulted in the concept of the Controller component), was really a by- product of addressing complexities inherent to the host platform. Today'’s development environments have come a long way in shielding developers from such complexities, making divisions between device input and output at the application level unnecessary. In such environments, an application of the Model-View-Controller pattern may result in an approach which adheres to the intent of the pattern while not following its original form, or adheres to its original form without following its original intent. Within many development environments, the original goals of the Model- View-Controller pattern can be accomplished today by merely separating an application’'s Forms and associated Controls from its domain model. The formalizing of a Controller for intercepting user input is unnecessary in platforms which natively provide this functionality. When attempting to follow the original form of the Model-View- Controller pattern within such development environments, the resulting architecture may fall somewhere between a strict implementation of MVC which goes against the grain of the hosting environment and an implementation which assigns different responsibilities to the original components. From this observation it can be deduced that the Model-View- Controller pattern isn’'t adequately distilled into pattern language. That is to say, the components prescribed by the MVC pattern are not agnostic of the assumed development environment, and most descriptions do not make this explicit. This often results in a misappropriation of the pattern. http://www.aspiringcraftsman.com/2007/08/interactive-application-architecture/ I seriously doubt that people are arriving at the Pyramid party with a pellucid pre-existing semantics for the term model that would act to hinder their comprehension of how the term is used within Pyramid. Name clashes and misnomers occur all through this particular domain of discourse - yet very few Pylons devs would seem to have had any conceptual difficulty in distinguishing http session from database session, for example. Chris has mentioned that there is an editor working on the docs ATM. I'd much rather see the results of that exercise before attempting to impose this additional misappropriation. I'm fairly certain that we're facing a problem of articulation, not terminology. For example, model graph (used in the Pyramid docs) suffers from the same difficulty as does little baby. It unnecessarily complicates the narrative with a tautological conceptual entity. 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. I think that's omitting a couple of key aspects of Pyramid's implementation of traversal. Firstly, collections are also publishable, so must also be counter-intuitively termed a resource - a collection is just as much a resource as one of the individual members of the collection. Secondly: the description omits to mention the role played by context in the traversal implementation. In that respect the analogy with a hierarchical file system is close but it is inadequately expressive for its intended purpose. - -- Cheers, Graham http://bel-epa.com/gjh/ -BEGIN PGP SIGNATURE- iEYEARECAAYFAk0LUgoACgkQOsmLt1NhivzBTACghwgMAL7/iIXgySiUHUxwUy72 ewcAn0/AEgfUb+v5dmqI3r6tEIoNQbgIiQCVAgUBTQtSClnrWVZ7aXD1AQKC+wP+ ObPItGM1k0R1vJg5OAzSDGSw5XVLkUH8PnY7kfMdGC8efkMkAwpGddeT2CWkn3zb +cLBP7K75meLIw1TI6aBXTvvH4s1DVfCY2vIUmYHxxxSQ0IMKsfNPAFYW4IlvinD
Re: pyramid terminology: model-resource
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. I don't think node is as meaningless as the others. It seems commonly understood to be a position in a graph, offering a fairly good correspondence AFAICT. Thanks, Kent -- 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.
Re: pyramid terminology: model-resource
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17 Dec 2010, at 04:57, Mark Ramm wrote: I think resource is a good term for items in the graph As did Tim Berners-Lee when he coined the referents URI and URL. Note that a URI is still termed a resource even if it does not have a corresponding resolvable URL. Also, the R in URI/URL is the central concept in RDF (Resource Description Framework). Where Pyramid's bfg heritage brings it a directed acyclic graph for a model, RDF uses a directed labelled (hence acyclic) graph for modelling. In the context of the web, the prior claims on resource have a far more cogent semantics than any prior claims on model might have and I fear that there'd be a horrible resource train wreck ahead for Pyramid. I think it is futile to strive after terminological precision in this area. Given that the core of the problem is an anticipated confusion over the semantics of model, I'll include this fragment of a discussion of MVC that I found rather useful: ... the Model-View-Controller pattern had the primary design motivation of separating presentation from domain concerns. The division between the input and output of the application (which resulted in the concept of the Controller component), was really a by- product of addressing complexities inherent to the host platform. Today'’s development environments have come a long way in shielding developers from such complexities, making divisions between device input and output at the application level unnecessary. In such environments, an application of the Model-View-Controller pattern may result in an approach which adheres to the intent of the pattern while not following its original form, or adheres to its original form without following its original intent. Within many development environments, the original goals of the Model- View-Controller pattern can be accomplished today by merely separating an application’'s Forms and associated Controls from its domain model. The formalizing of a Controller for intercepting user input is unnecessary in platforms which natively provide this functionality. When attempting to follow the original form of the Model-View- Controller pattern within such development environments, the resulting architecture may fall somewhere between a strict implementation of MVC which goes against the grain of the hosting environment and an implementation which assigns different responsibilities to the original components. From this observation it can be deduced that the Model-View- Controller pattern isn’'t adequately distilled into pattern language. That is to say, the components prescribed by the MVC pattern are not agnostic of the assumed development environment, and most descriptions do not make this explicit. This often results in a misappropriation of the pattern. http://www.aspiringcraftsman.com/2007/08/interactive-application-architecture/ I seriously doubt that people are arriving at the Pyramid party with a pellucid pre-existing semantics for the term model that would act to hinder their comprehension of how the term is used within Pyramid. Name clashes and misnomers occur all through this particular domain of discourse - yet very few Pylons devs would seem to have had any conceptual difficulty in distinguishing http session from database session, for example. Chris has mentioned that there is an editor working on the docs ATM. I'd much rather see the results of that exercise before attempting to impose this additional misappropriation. I'm fairly certain that we're facing a problem of articulation, not terminology. For example, model graph (used in the Pyramid docs) suffers from the same difficulty as does little baby. It unnecessarily complicates the narrative with a tautological conceptual entity. 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. I think that's omitting a couple of key aspects of Pyramid's implementation of traversal. Firstly, collections are also publishable, so must also be counter-intuitively termed a resource - --- a collection is just as much a resource as one of the individual members of the collection. Secondly: the description omits to mention the role played by context in the traversal implementation. In that respect the analogy with a hierarchical file system is close but it is inadequately expressive for its intended purpose. - -- Cheers, Graham http://bel-epa.com/gjh/ -BEGIN PGP SIGNATURE- iEYEARECAAYFAk0LQ6YACgkQOsmLt1NhivzhdgCeOphkZde4AnntnfZDCjiC5uKf jZUAoPC4PRuPI42y7EgylNHKz7VeDqvAiQCVAgUBTQtDplnrWVZ7aXD1AQId/wP9 GtPilYBUF6juBFSpRN5DFHZXFnAE3vZv7h9eMdgtXSHUir3SD6CS7pj//ulr9ri1 d1U/dzHhKX9Jzr4ZIGlWdlGo+Dy6aThe8XwOCLXHnD5CwBd2q1qxxgpxpXmS8t/F
Re: pyramid terminology: model-resource
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 /me tries yet again (good grief Google, get a grip) On 17 Dec 2010, at 04:57, Mark Ramm wrote: I think resource is a good term for items in the graph As did Tim Berners-Lee when he coined the referents URI and URL. Note that a URI is still termed a resource even if it does not have a corresponding resolvable URL. Also, the R in URI/URL is the central concept in RDF (Resource Description Framework). Where Pyramid's bfg heritage brings it a directed acyclic graph for a model, RDF uses a directed labelled (hence acyclic) graph for modelling. In the context of the web, the prior claims on resource have a far more cogent semantics than any prior claims on model might have and I fear that there'd be a horrible resource train wreck ahead for Pyramid. I think it is futile to strive after terminological precision in this area. Given that the core of the problem is an anticipated confusion over the semantics of model, I'll include this fragment of a discussion of MVC that I found rather useful: ... the Model-View-Controller pattern had the primary design motivation of separating presentation from domain concerns. The division between the input and output of the application (which resulted in the concept of the Controller component), was really a by- product of addressing complexities inherent to the host platform. Today'’s development environments have come a long way in shielding developers from such complexities, making divisions between device input and output at the application level unnecessary. In such environments, an application of the Model-View-Controller pattern may result in an approach which adheres to the intent of the pattern while not following its original form, or adheres to its original form without following its original intent. Within many development environments, the original goals of the Model- View-Controller pattern can be accomplished today by merely separating an application’'s Forms and associated Controls from its domain model. The formalizing of a Controller for intercepting user input is unnecessary in platforms which natively provide this functionality. When attempting to follow the original form of the Model-View- Controller pattern within such development environments, the resulting architecture may fall somewhere between a strict implementation of MVC which goes against the grain of the hosting environment and an implementation which assigns different responsibilities to the original components. From this observation it can be deduced that the Model-View- Controller pattern isn’'t adequately distilled into pattern language. That is to say, the components prescribed by the MVC pattern are not agnostic of the assumed development environment, and most descriptions do not make this explicit. This often results in a misappropriation of the pattern. http://www.aspiringcraftsman.com/2007/08/interactive-application-architecture/ I seriously doubt that people are arriving at the Pyramid party with a pellucid pre-existing semantics for the term model that would act to hinder their comprehension of how the term is used within Pyramid. Name clashes and misnomers occur all through this particular domain of discourse - yet very few Pylons devs would seem to have had any conceptual difficulty in distinguishing http session from database session, for example. Chris has mentioned that there is an editor working on the docs ATM. I'd much rather see the results of that exercise before attempting to impose this additional misappropriation. I'm fairly certain that we're facing a problem of articulation, not terminology. For example, model graph (used in the Pyramid docs) suffers from the same difficulty as does little baby. It unnecessarily complicates the narrative with a tautological conceptual entity. 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. I think that's omitting a couple of key aspects of Pyramid's implementation of traversal. Firstly, collections are also publishable, so must also be counter-intuitively termed a resource - a collection is just as much a resource as one of the individual members of the collection. Secondly: the description omits to mention the role played by context in the traversal implementation. In that respect the analogy with a hierarchical file system is close but it is inadequately expressive for its intended purpose. - -- Cheers, Graham http://bel-epa.com/gjh/ -BEGIN PGP SIGNATURE- iEYEARECAAYFAk0LeeIACgkQOsmLt1NhivwmhACgmXgcDvmF/p9Z68YoHHUl+Ijv ZAIAn3L7IBH9JnaF3c1jzfwHtYML9pQ1iQCVAgUBTQt54lnrWVZ7aXD1AQLPiQQA 3jn5tIHG1jsvXTdwfiCAgJmk83Mll02LMzXJAbP6JCFMKOt8Lr7U7p6TOY8kz4t3
Re: pyramid terminology: model-resource
On 17/12/2010 12:37, Marius Gedminas wrote: On Thu, Dec 16, 2010 at 11:57:42PM -0500, Mark Ramm wrote: 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. This is a nice explanation. I was just catching up on this thread and about to +1 Resource, now I get to +1 both Resource and this explanation :-) cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- 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.
Re: pyramid terminology: model-resource
Am 17.12.2010 15:42 schrieb Graham Higgins: For example, model graph (used in the Pyramid docs) suffers from the same difficulty as does little baby. It unnecessarily complicates the narrative with a tautological conceptual entity. This btw is another reason why I don't like the term model. Some people seem to use it for the whole graph or database scheme, others seem to use it for a single node or entity. This always confuses me. The terms resource or location do not have this problem. -- Christoph -- 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.
Re: pyramid terminology: model-resource
As a relative newcomer to Python web development (although I'm an experienced developer in other respects) I don't find the word 'model' confusing so long as it is qualified with the word 'traversal' as in 'traversal model'. Almost any non-trival application uses the word model contextually, with one or more of the following present (domain model, data model, application model, execution model, numerical model, concurrency model, proxy models, meta models ... ad infinitum). Humans are good at context, so we get by just fine and this is rarely a problem in practice. Talking about 'Pyramid models' could be confusing; talking about 'Pyramid traversal models' is not. I found the description of 'models' in the Pyramid documentation cogent and unambiguous. Using 'traversal model' would improve it further. For what it's worth, in my first adventures with Pyramid where I want to use a preexisting Python domain model (coincidentally ZODB based - but that's strictly an implementation detail) I'm inserting a traversal model consisting of what I'm calling 'Nodes' between Pyramid and my domain model. I used 'Node' because of the fact that traversal is clearly traversing a graph, graphs consist of nodes and because 'vertex' (the other word for graph nodes) seems inappropriate in this context - possibly because the graph edges aren't modelled explicitly. I took this approach because the __getitem__ API expected by traversal doesn't fit well with my existing domain model, so my traversal model serves as a kind of adapter. I suspect many people with existing domain models wanting to use traversal will find themselves in the same boat. As has already been pointed out most of the other candidate words are also heavily overloaded in this domain so maybe trying to find *one *word which captures the essence of traversal is a fools errand, and we should settle for the *two* words in 'traversal model'. Rob Smallshire On 17 December 2010 18:22, Chris Withers ch...@simplistix.co.uk wrote: On 17/12/2010 12:37, Marius Gedminas wrote: On Thu, Dec 16, 2010 at 11:57:42PM -0500, Mark Ramm wrote: 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. This is a nice explanation. I was just catching up on this thread and about to +1 Resource, now I get to +1 both Resource and this explanation :-) cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- 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.compylons-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.
Re: pyramid terminology: model-resource
On Fri, Dec 17, 2010 at 10:09 AM, Christoph Zwerschke c...@online.de wrote: Am 17.12.2010 15:42 schrieb Graham Higgins: For example, model graph (used in the Pyramid docs) suffers from the same difficulty as does little baby. It unnecessarily complicates the narrative with a tautological conceptual entity. This btw is another reason why I don't like the term model. Some people seem to use it for the whole graph or database scheme, others seem to use it for a single node or entity. That's another issue. :) To me and MVC, the model is the entire structure of domain logic. To Django, GAE and Simpycity, it's a class representing a table. Pyramid has veered toward the latter with models.py. But when we considered changing it tomodel as Pylons does, it became clear that symmetry with handlers.py, views.py, and templates --all plural -- was more important than defining what exactly is encompassed in a single model. -- Mike Orr sluggos...@gmail.com -- 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.
Re: pyramid terminology: model-resource
By the way, I earlier suggested reorganizing the manual to put the URL Dispatch chapter first and then the Traversal and Hybrid chapters. Putting Traversal first is a significant stumbling block for those who aren't used to it. The outline I suggested is here: http://groups.google.com/group/pylons-devel/browse_thread/thread/51ad2c8713924798/b0f1c3e93ba0b571 I also think the Unix example has to go. Don't focus on what the dumb Unix user doesn't know. Just say, We look up things like a filesystem does, so when we specify /a/b/c, it consults the root directory to find a, then it sees that a is a directory so it consults it to find b, then it does the same with b to find c. AFAIK the Unix, Mac, and Windows filesystems all work like this. -- Mike Orr sluggos...@gmail.com -- 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.
Re: pyramid terminology: model-resource
+1 'resource' is awesome. I retract all my previous objections. Thanks wordsmiths Mark and Chris. -- 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.
Re: pyramid terminology: model-resource
On Thu, Dec 16, 2010 at 8:57 PM, Mark Ramm mark.mchristen...@gmail.com wrote: 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. +1 for Resource Tree. That's also more understandable than directed acyclic graph, which sounds like mysterious Computer Science mumbo jumbo. Everybody understands a directory tree, and most people understand nested dicts. 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. +0 -- Mike Orr sluggos...@gmail.com -- 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.
