On Nov 16, 2005, at 1:52 AM, David Binger wrote:
> On Nov 15, 2005, at 3:20 PM, mario ruggier wrote:
>
>> I'd also be interested of ideas of how best to add this onto qp...
>> but ill take that to that list.
>
> The Hit class has an "info" field whose purpose is to support
> things like your page_info dictionary, so feel free to use it.

Yes, I had immediately thought of such a use for the Hit.info field
when I noticed it first.

Thinking about this some more, it seems to me that there are 2
essentially independent collections of information that could be used
to improve the building of a response in the various ways mentioned
earlier. Waiting for more inspired names, I identify these 2 objects as
an "export_info" and a "content_info" object. These have the
characteristics :

export_info
- Concerns "external" information about the (URL-addressable) export
- Attribute values are never modified during processing of a hit
- Directory.get_exports() returns an iterable of such instances
- Currently is defined as a 4-tuple: (export_name, internal_name,
crumb, title)

content_info
- Concerns "internal" information about a view that may be used when
serving a request to a specific export. Depending on the
application/context, there could be different views employed at
different times, when serving a response.
- Attribute values actually depend on the content type of the response,
but we are primarily interested in html (with css and javascript, etc).
- content_info objects for a given view of a given export are modified
liberally when building the view data.

Irrespective of a module for more evolved page-building support, such
as what I am contemplating, it seems to me that it would generally be
of benefit to formalize the export_info object, such that should an
application need to add a piece of information "about" the export, it
could do it here, naturally. In addition, the qp framework itself may
want to add such information on this object, and having it as an
explicit type would be less fragile than a 4-tuple.

Examples of what *may* go in subclassed ExportInfo object are anything
that we would wish to centralize the handling for, when serving a
request for an export, such as :
- accessibilty: e.g. must be logged in, must be admin, needs a specific
user permission, etc.
- navigation: under what user conditions should this export appear (or
disappear) in navigation menus, e.g. an export for which current user
has no access rights may still appear in menu, or an export that we
want to appear only for anonymous users and thus disappear for
authenticated users. (Note qp does a simple version of this,
essentially if crumb is None then it does not show up in the menu.)

As for the content_info object, this will be of no concern to qp at
all, so I am not worried about it too much at this point. It will
contain things previously mentioned, such as bits of js/css codes and
files, maybe meta tags, unique name prefixes for page, etc., all to
help reduce the plumbing for building html pages.

An explicit export_info type may seem like a complication, compared to
the simplicity of a 4-tuple. But it would somewhat open up the
framework to some interesting possibilities, as well as improve the
defense against future changes on the current 4-tuple export_info
object. What does everyone think about this?

mario