On Jun 23, 2005, at 2:31 PM, Alec Flett wrote: One general concern that I'm having is that the ItemCollection spec seems to be very focused on rules and setting attributes on items as a way of including them in collections... Chandler, as an end user application, deals primarily with ItemCollections of arbitrary items, created by the user, with no particular "rule" binding them together. i.e. a user creates an item, or drags it from one collection to another. There's no "rule" per say on most collections - we need to be thinking more about the use cases of inclusions, not rules. Today there are no rules on most collections, but the future direction is definitely to be able to define collections in terms of attributes on items. The problem with inclusions is that you have to know a priori of the existence of a collection so that you can remember to call add on it. But this is not going to work for collections defined by third party extensions.
The out of the box collections are the ones that are not focused on rules. But many other collections will be defined by rules. Think of attributes of items as defining facets, and rules as a way of assembling a faceted classification system. If you want to explicitly add items to a collection we can do that, but I don't think that supports the virtuality requirements that we have.
Um, it is linked. See the end of the background section. When you filter, you apply a boolean condition to each element of a set, " retaining" those items which match the collection. You filter a set by creating a filtered set, just like creating a union or intersection.except that the filter seems to be applied after the inclusions has been processed, whereas rules seem to be applied before the inclusions are processed. Do I have that right? This has implications, see below.. The items satisfying the rules and the items in inclusion are unioned. There's no precedence other than the elimination of duplicates. If we wanted a different definition of what an item collection is, it should be easy to do with the new set stuff. That filtered set is then the thing that you interact with. You still have access to the set that the filtered set is based on. The filtered set is dependent on the original set, and changes to the original set will cause the contents of the filtered set to update. If the app wants to turn off the filter, it can go back to referencing the original set.Right, I guess the use case you describe conflicts with how Chandler uses filters today, and I'm not sure which model is the expected one for Chandler going forward. Today, Chandler creates a sort of "child" collection which is a filtered version of an existing collection. You can get to the original collection via the .source attribute on the filtered collection. How should this be implemented going forward? A filtered collection will be created with an existing collection as its source/child. What you said and what I said are the same thing.
Today when you call add, the item is added to the inclusions and the result set. If we want to preserve that behavior (having an ItemCollection kind versus not) it is no problem to do that.
If you remove an item from inclusions (and it's not excluded) then it will be in the contents of the item collection. If you create a filter using the ItemCollection as source, then the filter will drop items that don't match its criteria.
see above.
How can you know all the places where that item should appear, according to virtuality rules. If you define the collection correctly, creating and removing events will just happen. This has always been the model for how we do things -- look at the Item Collection section of <http://viewcvs.o11n.org/chandler/trunk/chandler/parcels/osaf/views/main/parcel.xml>. Most of those collections have a rule. Today when you create items of a particular kind, those items automatically appear in collections whose base rule is set up to include items of a particular kind. Users will write rules (if they want to) when creating collections, not when creating or deleting items. This is not a change from the way we do it today.
Well, you could just create an attribute on the specific ItemCollection instance, but that attribute won't persist. It sounds to me like you want some kind of persistent dict that you can shove the metadata into. Ted |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
