Mailing List Archive

On Thu, 13 Jan 2000, Paul Everitt wrote:

> Mike--
>
> Do you think we'll have a per-role interface? If so I'll add it to the
> docs.

It might make sense to have a Reviewer interface. Hmm. My
inclination is to use the same box/interface as everything else, perhaps
under a heading with the role that granted the ability to you, such as
something like...

Portal Box
---
Member
New stuff
My stuff
Log off
[.Perhaps some stuff to learn about the present object's owner, 'Owner
profile'? For emailing the author, etc.]
Reviewer
Catalog item
Approve item
Reject item
Owner
Manage this
Request cataloging
Undo
Advanced

Mike.

--
Mike Pelletier email: mike@digicool.com
Mild mannered software developer icq: 7127228
by day, super villain by night. phone: 519-884-2434

For our sample portal I think that most of the non-Manager roles will
have the same interface (perhaps Reviewers will have a box showing what
they need to look at). However, I'm just trying to provide a facility
that lets the interface be extended/trimmed on a per-role basis.
Someone might come up with an arbitrary new role and change the way it
looks.

--Paul

Mike Pelletier wrote:
>
> On Thu, 13 Jan 2000, Paul Everitt wrote:
>
> > Mike--
> >
> > Do you think we'll have a per-role interface? If so I'll add it to the
> > docs.
>
> It might make sense to have a Reviewer interface. Hmm. My
> inclination is to use the same box/interface as everything else, perhaps
> under a heading with the role that granted the ability to you, such as
> something like...
>
> Portal Box
> ---
> Member
> New stuff
> My stuff
> Log off
> [.Perhaps some stuff to learn about the present object's owner, 'Owner
> profile'? For emailing the author, etc.]
> Reviewer
> Catalog item
> Approve item
> Reject item
> Owner
> Manage this
> Request cataloging
> Undo
> Advanced
>
> Mike.
>
> --
> Mike Pelletier email: mike@digicool.com
> Mild mannered software developer icq: 7127228
> by day, super villain by night. phone: 519-884-2434

On Thu, 13 Jan 2000, Paul Everitt wrote:

> For our sample portal I think that most of the non-Manager roles will
> have the same interface (perhaps Reviewers will have a box showing what
> they need to look at). However, I'm just trying to provide a facility
> that lets the interface be extended/trimmed on a per-role basis.
> Someone might come up with an arbitrary new role and change the way it
> looks.

Or they might come up with an arbitrary new portal object, or a member
might want to add custom items to the menu, or whatever. Mmmkay, how's
this--

Standard header calls and includes the result from a method on the
portal object, say 'interface_elements' for the time being.
'interface_elements' asks any relevant objects for a list of interface
items they would like to have presented. This would be the presently
displayed object, the user object, the portal object, and maybe others.
Each of these objects would return a sequence of dicts. The dicts are
built as such:

'interface_element' : optional field indicating which box this item
should end up in. If no value given, assume
'Portal Box' or what-have-you.

'section' : If the interface elements are to be divided into sections
with (or without) headings, this indicates which section to
place it in.

'caption' : The label of the link

'action' : The target of the link

Any additional items in the dict will be taken as parameters for the
action.

So, interface_elements() takes all the items, groups them by
'interface_element', and calls some template once for each group. The
template is to create a discrete box/menu/popup/whatever each time it's
called. If we want to get really tricky, we could have a different
template (or object) for each value of 'interface_element', so they could
render differently and have options like expand/collapse, etc.

Objections, suggestions?

Mike.

--
Mike Pelletier email: mike@digicool.com
Mild mannered software developer icq: 7127228
by day, super villain by night. phone: 519-884-2434