Forum OpenACS Development: Response to Sub-package site nodes API thought

Collapse
Posted by Don Baccus on
Re "The Permissions UI does not only allow you to work with one object, it can present a list of objects to assign permissions to": This isn't the way I implemented it with my site map/permissions UI fix, and it isn't the way I wanted to implement it. When you want to manage permissions for a site node, a bug-tracker, or a bboard, I want the permissions UI to appear as if it belonged to the site node, bug-tracker, or bboard instance. Not as part of a generic "permissoins" UI.

The latter is a verb-object type of thinking (I want to set permissions, now let me pick the object), whereas the Macintosh idea is object-verb (here's my bug-tracker, now I want to set permissions for it). I think object-verb is superior.

So, to be concrete, my context bar wouldn't include the "pick an object to set permissions for" page, it would go straight from bboard to the page setting permissions for bboard.

Exactly. Lars. This was exactly the thinking hat led me to implement my ugly-but-smart context bars at birdnotes.net. What the hell use is a context bar without context???

If a user goes the the "site guide" section, pokes around National Wildlife Refuges, finds "Malheur NWR", clicks on "enter data" ...

they want a context bar that sez "Site Guides: National Wildlife Refuges: Malheur NWR: Enter Data"

not a generic context bar that nests back to wherever "enter data" happens to live in the site map. Birdnotes has more than one place that leads to data entry and editing and my goal was to make those data management pages appear with sensible navbars that reflect where they are in the context of how they got there.

Navigation in the ACS has been a major whipping boy of mine for a long time (birdnotes has been around two-three years now) and if we can come up with a less obscene solution than the ugly-URL solution which should most definitely implement it.