redirect and Who, About and Date

Thanks for the quick response John...see more in-line

On Mar 8, 2006, at 4:19 PM, John Anderson wrote:

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

Hmm, might there be a way for an end-user to force the view
to  
display something different? ie. Delete To: John and replace
it with  
From: Mimi. Or right click on the cell and choose which
Who-type  
attribute to display. (Not necessarily for 0.7.)

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

Cool. I think of this more as: FromMyPerspectiveWho versus
the GroupWho

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

Mimi Yin wrote:
>
>>> + Could a user change which attribute to feed
into the explicit Who 
>>> attribute? e.g. Show To: instead of From:
> Hmm, might there be a way for an end-user to force the
view to display 
> something different? ie. Delete To: John and replace it
with From: 
> Mimi. Or right click on the cell and choose which
Who-type attribute 
> to display. (Not necessarily for 0.7.)
>
If I understand you correctly, the simplest way I can think
of doing 
something like this would be to do the equivalent of adding
a new column 
with the new attribute.

We run into problems whenever we try to make these
attributes "computed 
only", e.g. not stored in the repository (because
search only works for 
things stored in the repository); or when we store them in
the 
repository and we need to change all the values when the
view changes 
(potentially a slow operation).

John
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

I guess what I'm asking is:
Can we store a different Who attribute on a per-item basis?

Within a single view (e.g. the Dashboard), can we have 2
incoming  
items and for one of them, feed the <From: attribute>
to the <Who:  
attribute>; and for the other one, feed the <To:
attribute> to the  
<Who: attribute> for another one. In other words, can
we allow the  
user to over-write whatever logic we specify in the Python
code to  
feed attribute into the Who: column? There wouldn't be any
computed  
attributes involved.

This isn't a requirement, I'm just asking to understand
where the  
boundaries are.

Mimi

On Mar 8, 2006, at 4:45 PM, John Anderson wrote:

>
>
> Mimi Yin wrote:
>>
>>>> + Could a user change which attribute to
feed into the explicit  
>>>> Who attribute? e.g. Show To: instead of
From:
>> Hmm, might there be a way for an end-user to force
the view to  
>> display something different? ie. Delete To: John
and replace it  
>> with From: Mimi. Or right click on the cell and
choose which Who- 
>> type attribute to display. (Not necessarily for
0.7.)
>>
> If I understand you correctly, the simplest way I can
think of  
> doing something like this would be to do the equivalent
of adding a  
> new column with the new attribute.
>
> We run into problems whenever we try to make these
attributes  
> "computed only", e.g. not stored in the
repository (because search  
> only works for things stored in the repository); or
when we store  
> them in the repository and we need to change all the
values when  
> the view changes (potentially a slow operation).
>
> John

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

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

At 04:58 PM 3/8/2006 -0800, Mimi Yin wrote:
>I guess what I'm asking is:
>Can we store a different Who attribute on a per-item
basis?
>
>Within a single view (e.g. the Dashboard), can we have 2
incoming
>items and for one of them, feed the <From:
attribute> to the <Who:
>attribute>; and for the other one, feed the <To:
attribute> to the
><Who: attribute> for another one. In other words,
can we allow the
>user to over-write whatever logic we specify in the
Python code to
>feed attribute into the Who: column? There wouldn't be
any computed
>attributes involved.
>
>This isn't a requirement, I'm just asking to
understand where the
>boundaries are.

It's certainly *possible*, if perhaps not advisable for
user-level control 
on a per-item basis.  We would have to have additional
fields to *store* 
that choice, for each field that allows a choice, on every
single item.

However, it's definitely possible for individual kinds to
do this 
programmatically on a per-item basis (e.g. by detecting
whether a message 
is outbound or inbound), which is probably more useful in
the short term 
and doesn't impose any additional storage overhead.

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

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

Mimi Yin wrote:
> I guess what I'm asking is:
> Can we store a different Who attribute on a per-item
basis?
>
> Within a single view (e.g. the Dashboard), can we have
2 incoming 
> items and for one of them, feed the <From:
attribute> to the <Who: 
> attribute>; and for the other one, feed the <To:
attribute> to the 
> <Who: attribute> for another one. In other words,
can we allow the 
> user to over-write whatever logic we specify in the
Python code to 
> feed attribute into the Who: column? There wouldn't be
any computed 
> attributes involved.
Yes, as long as there is something about the item that
allows us to know 
which attribute to assign to who, e.g. the Kind of Item, or
an attribute 
on the item indicating the source of who.
>
> This isn't a requirement, I'm just asking to
understand where the 
> boundaries are.
>
> Mimi
>
> On Mar 8, 2006, at 4:45 PM, John Anderson wrote:
>
>>
>>
>> Mimi Yin wrote:
>>>
>>>>> + Could a user change which attribute
to feed into the explicit 
>>>>> Who attribute? e.g. Show To: instead of
From:
>>> Hmm, might there be a way for an end-user to
force the view to 
>>> display something different? ie. Delete To:
John and replace it with 
>>> From: Mimi. Or right click on the cell and
choose which Who-type 
>>> attribute to display. (Not necessarily for
0.7.)
>>>
>> If I understand you correctly, the simplest way I
can think of doing 
>> something like this would be to do the equivalent
of adding a new 
>> column with the new attribute.
>>
>> We run into problems whenever we try to make these
attributes 
>> "computed only", e.g. not stored in the
repository (because search 
>> only works for things stored in the repository); or
when we store 
>> them in the repository and we need to change all
the values when the 
>> view changes (potentially a slow operation).
>>
>> John
>
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

Phillip J. Eby wrote:
> It's certainly *possible*, if perhaps not advisable
for user-level 
> control on a per-item basis.  We would have to have
additional fields 
> to *store* that choice, for each field that allows a
choice, on every 
> single item.
>
> However, it's definitely possible for individual kinds
to do this 
> programmatically on a per-item basis (e.g. by detecting
whether a 
> message is outbound or inbound), which is probably more
useful in the 
> short term and doesn't impose any additional storage
overhead.
>
I also think that what Mimi is talking about is more of a
user-level 
(i.e. view-level) issue than a model-level issue. Perhaps
the view could 
annotate the model to indicate which attributes it cares
about?

In fact, I kind of wonder if this whole concept of
who/about/etc is 
really a view-level annotation on specific kinds.

(I'm not wed to this idea, but I thought I'd throw it out
there)

Alec

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