On Nov 22, 2005, at 4:03 PM, David Binger wrote:
> 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.

My apologies, but I am not sure I see what you mean here... is it that
in your applications you have get_exports() returning a different thing
than [(external, internal, crumb, title)] ? If so, would you be able to
indicate how you manage access control in this way?

>> 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.)

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

Yes, I can see that this is easily done, and I think may be quite
workable in practice.

Thanks, mario