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

Collapse
Posted by Lars Pind on
Stephen,

I appreciate your challenge, that's what makes good ideas great (or kills bad ideas, whichever the current case represents 😉.

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.

Why do I think this is important? Because the alternatives are even worse. You can either have the permissions page not have any context bar at all, which I think sucks, because you're leaving the user without his/her most familiar navigation tool (the context bar is still the only fixed piece of navigation in a default OpenACS installation). And having the context bar jump around in the case of permissions is confusing and doesn't portray any useful site map, especially given the totally useless nature of the permissions index page.

After having explored my initial design idea fully, I'm now convinced that it's an instance of overengineering. Let's put it to rest. But let's search for a decent alternative.

I like Dave's thought. How about the idea that, whenver you have such a "navigational subroutine", it must live in a subdirectory of its own. Then you can create the equivalent of a symlink from somewhere inside your own package to that directory. And then that, possibly along with some metadata, takes care of the navigation. (Forget about the paramters that go along with a node, they're not terribly important.)

Enough for now. Off to bed.

/Lars