Mimi Yin wrote:
Hi John, just wanted to clarify a couple of things:
+ How do we tell the summary table know which attribute to feed into
the explicit Who attribute? From, To, CC, BCC, Creator, Author, etc.
There's probably going to be some Python code that belongs to the Item's
Class that decides which attributes feed into the Who attribute.
+ Could a user change which attribute to feed into the explicit Who
attribute? e.g. Show To: instead of From:
Yes, by changing this Python code.
In the FUTURE, could we add logic to define different attributes to
feed into the Who attribute depending on what view you're in? In the
Dashboard view, feed the From: attribute into the Who: attribute. In
the OSAF Office calendar, feed the To: attribute into the Who: attribute.
Perhaps a better way to go is to have different Who attributes for
different views, e.g. the "DashboardWho". This would avoid having to
change all the Who attributes when you switched views, or the familiar
"computed attribute" problem if we didn't store "Who" attribute in the
repository.
This is related to the notion of Spheres. In the Dashboard, you want
to view items from the perspective of your "Personal Sphere." In the
Office calendar collection, you want to view items from the
perspective of the group or "Office Sphere".
Mimi
On Mar 8, 2006, at 3:48 PM, John Anderson wrote:
I'm planning on getting rid of redirect attributes to handle the Who,
About and Date attributes in the Summary Table. Instead I plan to add
an explicit Who, About and Date attribute. By noticing when
attributes that affect the value of Who, About or Date change (using
onValueChanged), I'll update Who, About and Date as necessary.
This is simple to implement and eliminates the current problem where
Who, About and Date sometimes doesn't display the correct value. It
also doesn't require a special "computed attribute" that isn't stored
in the repository, so you can always search for Who, About and Date
like any other attribute. Finally, it allows Andi to get rid of
redirect, which simplifies the repository design.
John
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
