[Chandler-dev] Future of redirectTo?

[Grant Baillie]

On 26 Jul, 2006, at 07:34, John Anderson wrote:

> I'm also in favor of getting rid of the redirectTo's and using  
> explicit attributes in their place.

Same here ... I think everyone's on board with this one :).

>
> Bryan Stearns wrote:
>> There are a couple of things happening that are calling our  
>> attribute-redirection strategy into question...
>>
>> - Bug 6387 (sorted index doesn't maintain sort) where we're trying  
>> to index a redirectTo attribute. I'm not sure what exactly is  
>> happening, but I can imagine: existing attribute redirection  
>> doesn't let the repository know when a redirect-source attribute  
>> has changed, so that it can update a redirect-target index.
>>
>> - The dashboard spec calls for more-complex multi-attribute  
>> sorting on some columns; some of the sorts call for collection  
>> indexes that will need to consider attributes on items other than  
>> the one in the collection: eg, when sorting the date column, an  
>> item needs to produce "the next interesting datetime", which could  
>> be the startTime if it's an event, or the datetime of the next  
>> tickler that's going to fire (and while the spec only calls for  
>> one tickler per item for now, there'll be multiple ticklers in the  
>> future).
> I'm a little confused on "the next interesting datetime", but could  
> it be solved by having adding a new attribute  
> "interestingDateTime" (which the sort uses), and is possibly  
> updated whenever an event's startTime is modified or it's tickler  
> time is updated? This is what I proposed in bug#6387 and seems like  
> what Jeffrey is proposing below.

Sure. But how exactly would this work: i.e. onValueChanged(),  
monitoring the changed values, or some other way? I'm a little wary  
of onValueChanged() becoming overly complex. In general, we want to  
index these attributes, so what I'd like to see is an API similar to  
what's now pim.Calculated:

class MyContentItem(ContentItem):

    def getInterestingDatetime(self):
        # ... perform possibly complex calculation
        return resultOfPossiblyComplexCalculation

    # optional: setInterestingDatetime

    interestingDatetime = schema.IndexedProperty(
                                   schema.DateTime,
                                   basedOn = ('startTime',  
'ticklers'), # basedOn == attributes in Indexed.addIndex()
                                   indexType = 'attribute', # could  
be 'string',
                                   fset = getInterestingDatetime)

This would create an attribute which is a property on the class, and  
also create the appropriate index (named the same as the attribute).  
Maybe it somehow caches the value so that getInterestingDatetime  
doesn't get called every time the attribute is accessed (though it's  
not clear that's necessary).

(FWIW, it's the index that ends up creating a monitor here to update  
when changes are made to the "source" attribute).

--Grant