-----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
86639Yys48tTlXQONBWRGkm6tyYDeA8V4vhkvNga+so=
=Ytcd
-----END PGP SIGNATURE-----
--
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.
