David Binger wrote:
> On Feb 28, 2005, at 3:51 PM, Mario Ruggier wrote:
>
>> Hi,
>>
>> i needed to put in place form-based login and page access control, and
>> looking around there are only bits and pieces of suggestions and code
>> to show how this is done. So I have tried to put them together into a
>> working demo, and extended altdemo.py, in qx2, to show how this can be
>> done in a clean idiom, using AccessControlled and _q_access and
>> NotLoggedInError.
>
> This may not matter, but the next Dulcinea release uses a different
> mechanism from before.
> Basically, it uses a a special exception to break out of the normal
> traversal, but the
> application code sets everything on the response before raising the
> "RespondNow" exception.
> This puts the formatting of "interrupted" traversals more directly
> under the control
> of the application program.
>
> I think Quixote would be be better if it used this pattern instead of
> PublisrErrors,
> but the change would be pretty disruptive to existing applications.

What do people use PublishError for?  It seems more like something the
Quixote framework would raise than an application would raise.  I can
usually find some justification to blame it on the user and raise
QueryError.  Otherwise I let Python's native exception propagate.
PublishError seems to mean something Quixote-specific or
publishing-specific is wrong, but it's hard to find a case for that in
application code.

RespondNow sounds intriguing.  Cheetah has a #stop directive which means,
"Take the document that has accumulated and exit early, using that as the
final."  Maybe something like that would be useful in Quixote
applications, although I'm not sure where.  In PTL I've more wanted to
    return 'something specific'
in if-branches rather than
    return   # Return whatever has accumulated.

Anything that makes AccessError or ._q_traverse() more modular is probably
a good idea.  ._q_traverse() has so many jobs -- choosing the URL method,
filtering output, access control -- that you sometimes have to subclass
the whole thing just to do something small.  Or else you have a confusing
chain of subclasses calling superclasses; complexity which is compounded
when ._q_traverse() is called recursively.  Perhaps define the broad
categories that applications will likely want to customize (authorization
and filtering) and provide hooks for them.  E.g., replace the innermost:

        return obj()

with:
        self._q_access()   # Risen from the dead!
        return self._q_filter( obj() )  # All 'decoration' stuff.

    def _q_filter(self, output):
        return output

or even:

        result = self._q_authorize()
        if result is None:
            result self._q_filter( obj() )

    def _q_authorize(self):
        return None

That would allow ._q_authorize() to raise an exception or return an
alternate document or redirect, or let it pass through by default.
(._q_access() if I remember needs a kludge to do redirects, and doesn't do
alternate documents without hacking.)

The user could plug in anything they wanted for ._q_authorize() or
.._q_filter(), or even a stack of subclass methods, all without touching
.._q_traverse().  One case might be a series of
section/subsection/subsubsection wrappers around documents.  And if
somebody dreams up a non-authorization reason to return an alternate
document, they can abuse ._q_authorize() for it.