[Grok-dev] Re: grokcore.view -> grokcore.browser

[Brandon Craig Rhodes]

Martijn Faassen <faassen at startifact.com> writes:

> I don't really like the convention 'browser' very much, nor do I think
> that 'browser' is such a good name.

+1

If it's not our own implementation of something like Firefox, as is
testbrowser, then we should not allow the word "browser" anywhere near it.
Browsers, by definition, browse things.

> An alternative would be 'Page'. Not ideal either, as the word 'Page'
> is not really used much in the package either (PageTemplate,
> BrowserPage), and is only represented as PageTemplate (and
> PageTemplateFile?) in __init__.py

The problem with View by itself, as you outlined, is that there can be
XML-RPC views of something too; and the problem with "BrowserView" is
that as soon as a Firefox plugin is invented for composing and viewing
the results of an XML-RPC call, it will be ambiguous what kind of
Browser is being given what kind of view, since conceivably developer-
oriented browsers will someday soon be able to display not only HTML
documents and RSS/Atom XML documents, as they do today, but raw syntax-
highlighted XML results, JSON function return values, and so forth.

So, just because someone's looking at a view with a browser does not,
even today, mean they're seeing rendered HTML, and as browsers become
more sophisticated that will be even less true.

A Grok View does not necessarily output HTML; a View's page template or
render() method can as easily produce JSON or Atom as it can produce
HTML.  The only thing that seems to unify Views, as opposed, say, to
Grok XML-RPC objects, is that XML-RPC obeys a certain protocol in its
output (it formats the function's Python result types as XML-RPC
values), whereas a normal View lets you output whatever kind of document
you want as your result.

Ah, there's the essential word: "document".  A View is used for
producing arbitrary documents as a result of HTTP requests; that's what
seems to set it apart from XML-RPC and JSON.  Let's break down what
inputs and outputs they expect.  On the input side:

 View - any content will be "multipart/form-data"
 XMLRPC - content will be "text/xml"
 JSON - content will be "application/json"

This is pretty symmetrical; they each know how to interpret and deliver
to update(), or another Python method, arguments encoded in three quite
different ways.  But on output:

 View - lets you return any document you wish!
 XMLRPC - takes your return value and turns it into XMLRPC
 JSON - takes your return value and turns it into JSON

If we want to name our classes according to what input they take, then a
View should really be "HTTPForm" or something, but that's silly, I
think, since View also gets the requests that provide no data at all;
it's sort of a general fall-back.  If we wanted to name our classes
according to the output they provide, then we could rename "View" to
"Page" since it's what you write if you want to be in complete control
of the document that gets returned, and "Page" seems an attractive and
brief name for any document that gets returned over HTTP.  But if,
finally, we wanted to highlight the fact that a View, because it lets
you return any kind of document instead of being constrained to a
particular output format, then we could just keep the name "View" since
that indicates that it's the general case that stands above the others
by being agnostic about what sort of output it returns.

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon