On Nov 22, 2005, at 2:54 AM, mario ruggier wrote:

>
> Examples of what *may* go in subclassed ExportInfo object are
> anything that we would wish to centralize the handling for,

The centralization of all these examples (below) already happens, in
our applications, in
the get_exports() method.

> 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?

The 4-tuple pattern seems very stable, so I for one would not put
energy into defending against possible changes in that pattern.

Anyone that wants a different way of defining exports, ExportInfo,
decorators, magic names, _q_exports, or whatever, can do that with
total freedom:  the QP (or Quixote) publisher does not care how your
root directory works, as long as it has a _q_traverse to call.

If you want to implement and ExportInfo pattern, I'd suggest
adding a 'get_export_info()' method that generates the sequence
of ExportInfo instances, and let your 'get_exports()' just
loop over these and return the 4-tuples.