In my opinion, a resource applies to the non-livable content such as images, videos, audios, dialog templates, icons, css/js scripts where those files cannot be executed within the program domain but very much useful within the domain like file rendering, file serving purpose. Again model tends to ORM intensive.
I propose UrlNode or UrlModel or Url (Could be conflict with existing Url package) where I like the term UrlNode which is very closer to the graph terminology. UrlModel seems to represent a model in a persistent world or ORM or DB. Regards, Krish On Dec 15, 10:13 pm, Chris McDonough <chr...@plope.com> wrote: > I'm considering making a fairly major terminology change to the Pyramid > docs. I'd like to consider renaming the term "model" to "resource" in > the docs. > > Since repoze.bfg 0.1, we've used the term "model" to refer to each > object that forms the graph used by traversal. This is due to Pyramid's > Zope heritage: in a "Zopey" Pyramid app, these objects are indeed > persistent "domain model" objects, as they are nodes in a ZODB. > Seehttp://docs.pylonshq.com/pyramid/dev/designdefense.html#pyramid-uses-... > > But Pyramid doesn't actually have an opinion about whether the objects > used for traversal are "domain model" objects. Pyramid applications can > be constructed that have a traversal graph which represents only a > "sitemap" or a "security graph"; the objects in such a graph aren't > necessarily "domain models". In such an application, the domain model > may live entirely outside the graph of objects used for traversal. It > would be useful to have another term for objects in the traversal object > graph. > > Why "resource"? Well, a URL is a "universal resource locator", and > traversal could indeed be used to locate a resource in this sense. It's > not a 100% correct mapping of terminology, because an HTTP resource is > the body of the HTTP response, and this is usually computed by a view. > But it's closer than "model". > > API side effects of such a renaming: > > pyramid.url.model_url -> pyramid.url.resource_url > "resource specification" -> "package asset specification" > > ... and perhaps a few other minor changes. Obviously we'll leave > backward compat shims for all changed APIs around so we don't break > existing code. > > Does anyone strongly agree or strongly disagree with this? > > - 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. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
