RedirectTo Evolution

The Issues

Attribute Redirection is not powerful enough to do everything we'd like it to do in the UI. We use this feature to unify the various notions of "who", "date", and "about", so the summary view can have columns that know how to determine the appropriate attribute for each item being displayed.

The problem in a nutshell is that the attribute to be displayed for a given item isn't constant. For an item of a given kind, it can change over time, or based on the value of another attribute. So we need to either change the redirection on an individual Item (currently redirection is specified on a Kind), or we need to be able to execute some code that determines which attribute to use. Even in the former case we'll need to execute code at certain times to change the redirect on an item as it evolves, so we're leaning towards the computed attribute model. However, computed attributes pose problems for searching, and so they need to be highlighted specially in the UI, so the user knows they are not static attributes.

From the repository perspective, the redirection causes trouble keeping ref-collection indexes up to date. Andi has a proposal to limit redirectTo to only redirect within the current item. This seems like a good idea, because we are not using the more general form that allows redirecting from item to item in any critical way.

Proposed Evolution

I propose we limit the current implementation of redirectTo as Andi has outlined. Going forward we need to develop a plan for a more powerful solution. The alternatives are:

1. Computed Attributes -- aka Properties
2. Item-based redirectTo capability

I think the cleanest alternative is to use computed attributes, which would work essentially like python properties -- they are accessed like attributes but trigger code execution to produce or modify the value. This will require support from both the repository and the UI (because properties will not be searchable).

Item-based redirectTo is a compromise between having the ability to recompute a redirection, and having the attributes be searchable. In theory, the system could recompute the redirection on an individual item when other attributes change, or as needed over time. But for any given moment, when a query might run, redirection would be fixed to point at a single attribute within the current item. Unfortunately, having a redirection capability on an Item level will probably slow down access to all attributes, which would probably be considered unacceptable.

Either way, I don't think there's a pressing need for this support in 0.5, so we have some time to think this through.

-- DonnDenman - 05 Nov 2004