* mario ruggier wrote [2005-11-25 15:43:56 +0100]:
> Ah, so you put the access control processing behind the get_exports()
> method. Yes, this seems a cleaner way to do it, helping also to keep
> the more upfront UI code untangled from access control complications.

I'm following, the Dulcinea (and now QP) pattern - access control is
managed within a directory object's get_exports() method. Within UI methods I
merely have to make a call to ensure_signed_in() if that method should be
executable by a particular known user (possessing, or not, permissions).


def SomeObjectDirectory(Directory):

    def get_exports(self):
        if get_user().is_admin():
            yield('someadminthing', 'someadminthing', 'Process Foo', None)
        if get_user().is_granted('moderate', self.someobject):
            yield('moderate', 'moderate', 'Moderate the thing', None)
        if get_user(): # logged in users only
            yield('dothis', 'dothat', 'Do This Crumb', 'Do This Title')
            # etc...
        if not get_user(): # not signed in
            # perhaps might need to yield up something appropriate
            yield('register', 'not_yet_a_user', None, None)

        # stuff everyone gets
        yield('thing1', 'thing1', None, None)
        # ...

    def someadminthing(self):
        ensure_signed_in()
        # ...

    def moderate(self):
        ensure_signed_in()
        # ...

    def not_yet_a_user(self):
        # here we don't want to ensure they are signed in!
        return registration_form()

    # etc...

Where possible I try to avoid sprinkling user tests in the UI methods
themselves but its not completely avoidable as there clearly are many times
when you want to show some additional capability to some users
(user.is_admin() for example) in the same stream of code dished up to other
users. The permissions system certainly helps in keeping that clean.

> But then you do need something like the equivalent of the ExportInfo
> objects somewhere in the system...

I've not found this myself as yet.