redirect and Who, About and Date

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
h
ttp://lists.osafoundation.org/mailman/listinfo/dev

John -
How do you handle when who/about/date are different types?
For instance, 
I think 'who' on some objects is a refList of
EmailAddresses but on 
other objects (Note?) it is a EmailAddress object.. or I
could imagine 
it eventually being a string too.

One solution I could imagine is putting separate, localized
'who' 
attributes on a per-Kind basis (so that e-mail addresses
could have its 
own 'who' that is a refList of EmailAddresses and Notes
could have just 
a single EmailAddress object.)

But if we're talking about a scheme like this, it seems
like it would 
make sense to just bake this into the schema layer, rather
than 
implement onValueChanged on each of the respective PIM
Kinds. Maybe pje 
can shed some light here?

Alec

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
> h
ttp://lists.osafoundation.org/mailman/listinfo/dev

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev"
mailing list
h
ttp://lists.osafoundation.org/mailman/listinfo/dev

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.
+ Could a user change which attribute to feed into the
explicit Who  
attribute? e.g. Show To: instead of From:

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.

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
h
ttp://lists.osafoundation.org/mailman/listinfo/dev

Hi John,

> 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.

Andi and I discussed a "bequeathTo" mechanism
which would be a more
declarative (and hopefully less error prone) way of
achieving what I
think you're looking for in your onValueChanged code.  I'm
not sure if
and where this is on Andi's plate, but if you can use this,
that might
save you some time.

> 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.

There's theoretical usefulness to redirect for reminders. 
I think we
backed off from using this in the current reminder code, but
it's worth
noting that the summary table isn't the only possible
consumer of redirect.

Sincerely,
Jeffrey
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev"
mailing list
h
ttp://lists.osafoundation.org/mailman/listinfo/dev

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
h
ttp://lists.osafoundation.org/mailman/listinfo/dev

At 04:02 PM 3/8/2006 -0800, Alec Flett wrote:
>John -
>How do you handle when who/about/date are different
types? For instance, I 
>think 'who' on some objects is a refList of
EmailAddresses but on other 
>objects (Note?) it is a EmailAddress object.. or I could
imagine it 
>eventually being a string too.
>
>One solution I could imagine is putting separate,
localized 'who' 
>attributes on a per-Kind basis (so that e-mail addresses
could have its 
>own 'who' that is a refList of EmailAddresses and
Notes could have just a 
>single EmailAddress object.)
>
>But if we're talking about a scheme like this, it seems
like it would make 
>sense to just bake this into the schema layer, rather
than implement 
>onValueChanged on each of the respective PIM Kinds.
Maybe pje can shed 
>some light here?

If I understand correctly, the idea here is to make them
*fixed* types: 
strings for who and about, and some date-time type for the
date.  The 
onValueChanged is there to handle the necessary
subclass-specific conversion.

To put it succinctly, the who/about/date attributes would
part of an 
interface defined by osaf.pim, which content items are
required to implement.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev"
mailing list
h
ttp://lists.osafoundation.org/mailman/listinfo/dev

On Wed, 8 Mar 2006, 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.

We recently discussed something related to this on IRC and
came up with a new 
attribute aspect, bequeathTo, that would allow you not to
have to use 
onValueChanged() to bequeath a value from an attribute to
another attribute 
after it changed.

I'm planning on implementing this in the next few weeks.

Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev"
mailing list
h
ttp://lists.osafoundation.org/mailman/listinfo/dev

At 05:43 PM 3/8/2006 -0800, Andi Vajda wrote:

>On Wed, 8 Mar 2006, 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.
>
>We recently discussed something related to this on IRC
and came up with a 
>new attribute aspect, bequeathTo, that would allow you
not to have to use 
>onValueChanged() to bequeath a value from an attribute
to another 
>attribute after it changed.
>
>I'm planning on implementing this in the next few
weeks.

So how does this work?  Is this only for copying attribute
values, or does 
it run some code when the dependent attribute changes?

For what we're talking about here, I don't think just
copying the value is 
going to suffice if type conversions are involved.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev"
mailing list
h
ttp://lists.osafoundation.org/mailman/listinfo/dev

On Wed, 8 Mar 2006, Phillip J. Eby wrote:

> At 05:43 PM 3/8/2006 -0800, Andi Vajda wrote:
>
>> On Wed, 8 Mar 2006, 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.
>> 
>> We recently discussed something related to this on
IRC and came up with a 
>> new attribute aspect, bequeathTo, that would allow
you not to have to use 
>> onValueChanged() to bequeath a value from an
attribute to another attribute 
>> after it changed.
>> 
>> I'm planning on implementing this in the next few
weeks.
>
> So how does this work?  Is this only for copying
attribute values, or does it 
> run some code when the dependent attribute changes?

No code is run, the value is taken as is and set into the
'heir''s attribute.

> For what we're talking about here, I don't think just
copying the value is 
> going to suffice if type conversions are involved.

The 'bequeathTo' aspect came up in the context of avoiding
item loading when 
running filter expressions in filter collections.
'bequeathTo' was meant as a 
way of increasing value locality by caching them on the item
being passed 
through the filter.

If any sort of smarts are needed to convert, conditionally
set, or otherwise 
go beyond a simple setting of the same value,
'bequeathTo', as discussed 
earlier, is not good enough. 'bequeathTo' was born as the
opposite of 
'inheritFrom' - hence its name - which also just returns
an inherited value, 
without any conversion.

Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev"
mailing list
h
ttp://lists.osafoundation.org/mailman/listinfo/dev

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.
I think we need to take a step back here and really nail
down how the 
end-user design ought to work.  Then we can figure out what
the right 
thing to do at the implementation level(s) ought to be.  

Ted
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev"
mailing list
h
ttp://lists.osafoundation.org/mailman/listinfo/dev

Hi John,

You are right, that was the spec back in 0.4 when the bug
was originally 
logged. I think the current plan is to come up with an
updated spec, 
sometime before alpha3. The new updated spec will take into 
consideration sharing and collaboration scenarios,
extensibility 
requirements (how 3rd party parcels might plug in), etc.

I've reassigned this bug to Ted, and it is scheduled for
alpha3.

Note that we are trying to respect the staging proposed by
the ppd team, 
so that they can schedule their work as well.

Cheers,
Katie

John Anderson wrote:
> I think Mimi has already nailed down how she thinks the
end-user design 
> ought to work. The following is taken from a spec
referenced in Bug 
> #2167: Who, Date, not always showing the right
attribute.
> 
>     * *Who column*
>     * Notes, Tasks, Events - Who - Blank (to the user)
>     * Messages - Who (from) or (to) - Display *from* if
it's incoming
>       mail. Display *to* if it's outgoing mail.
>     * Shared messages - Who (from) or (to) - Display
*from* if the
>       sender is me. Otherwise, display *to*.
> 
>     * *About column*
>     * [*OI^?
>       <http://w
iki.osafoundation.org/bin/edit/Glossary/OpenIssue?topicparen
t=Projects.SummaryTableViewSpec>*]
>       There is a proposal to change the About column to
be Subject for
>       all Kinds. Otherwise, it should be:
>     * Notes, Tasks, Calendar - About (Title) - Title
>     * Email - About (Subject) - Subject
> 
>     * *Date column*
>     * The following proposal is contingent on the
ability to display an
>       icon in the same cell as text in the summary
table widget
>     * Which date to display in order of priority:
>          1. Calendar date (if Alarm date is dependent
on the Calendar
>             date: ie. 15 minutes before)
>          2. Alarm date (even if there is a calendar
date so long as the
>             alarm date is a custom date)
>          3. Date sent or Date received
> 
> If you think this isn't the right way to go, you might
follow up with her.
> 
> John
> 
> 
> Ted Leung wrote:
>> 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.
>> I think we need to take a step back here and really
nail down how the 
>> end-user design ought to work.  Then we can figure
out what the right 
>> thing to do at the implementation level(s) ought to
be. 
>> Ted
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation
"Dev" mailing list
>> h
ttp://lists.osafoundation.org/mailman/listinfo/dev
> 
>
------------------------------------------------------------
------------
> 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> 
> Open Source Applications Foundation "Dev"
mailing list
> h
ttp://lists.osafoundation.org/mailman/listinfo/dev

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev"
mailing list
h
ttp://lists.osafoundation.org/mailman/listinfo/dev

It's not the summary table part of this that I think is
unclear, it's 
all the places in the system where we use
"redirection" or might use 
"redirection".   I put "redirection"
it quotes to distinguish the 
user-visible notion from the underlying implementation.

Ted

John Anderson wrote:
> I think Mimi has already nailed down how she thinks the
end-user 
> design ought to work. The following is taken from a
spec referenced in 
> Bug #2167: Who, Date, not always showing the right
attribute.
>
>     * *Who column*
>     * Notes, Tasks, Events - Who - Blank (to the user)
>     * Messages - Who (from) or (to) - Display *from* if
it's incoming
>       mail. Display *to* if it's outgoing mail.
>     * Shared messages - Who (from) or (to) - Display
*from* if the
>       sender is me. Otherwise, display *to*.
>
>     * *About column*
>     * [*OI^?
>       <http://w
iki.osafoundation.org/bin/edit/Glossary/OpenIssue?topicparen
t=Projects.SummaryTableViewSpec>*]
>       There is a proposal to change the About column to
be Subject for
>       all Kinds. Otherwise, it should be:
>     * Notes, Tasks, Calendar - About (Title) - Title
>     * Email - About (Subject) - Subject
>
>     * *Date column*
>     * The following proposal is contingent on the
ability to display
>       an icon in the same cell as text in the summary
table widget
>     * Which date to display in order of priority:
>          1. Calendar date (if Alarm date is dependent
on the Calendar
>             date: ie. 15 minutes before)
>          2. Alarm date (even if there is a calendar
date so long as
>             the alarm date is a custom date)
>          3. Date sent or Date received
>
> If you think this isn't the right way to go, you might
follow up with her.
>
> John
>


_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev"
mailing list
h
ttp://lists.osafoundation.org/mailman/listinfo/dev