Doesn't Andi and Ted's set idea, addresses the notion of most of these
issues?
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.
The only collections focused primarily on rules are "All" and maybe
this "Mine/Not-Mine" bit. Yes, you can imagine others, but its not the
common case.
Ted Leung wrote:
Mine/Not Mine is a feature of the sidebar. See section 5
of
<http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_6/Sidebar-0.6.html>
(cool, so it might be useful to at least x-reference & link this in
the IC spec so readers understand its purpose)
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..
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?
When you say you're "interacting" with the filtered set, I'm trying to
understand the actual implications of each operation (add/remove/etc)
when the filter itself is added and removed.
Here's a real world example: if a ItemCollection has a "Task" filter on
it, but I call ic.add(event) where event is not a task, what is the
result? Does the add() fail, or does the event get added to inclusions,
but not actually show up as a member of the collection since its not a
task?
Or what if I .remove() an item that's in inclusions, but doesn't match
the filter?
What are the implications when adding new
items such as when you create a new item and put it in the collection?
If it doesn't match the filter (i.e. adding a CalendarEvent to an
ItemCollection filtered on Tasks) does it get added to "inclusions"?
does it appear to be in the filtered collection or not?
If you want to add an item which doesn't match the rule then you will
need to add it to inclusions explicitly.
do you mean via .add() or via some other mechanism? It sounds like
filters trump inclusions, and inclusions trump rules.
If you have a collection based on a rule/filter then
creating items that match the rule is sufficient to get them into the
collection. Most of the time, you shouldn't need to worry about
where to add stuff, you should let the rules and extents do that work
for you.
This is what I'm talking about : Most of the time, the app does
care where to add the stuff. Most of the time, the user is
creating or deleting an event in a specific collection, not writing
rules.
If you want to associate metadata with ItemCollection then
we should have an Item Collection kind where that data can live. If
you add the metadata as attribute of the ItemCollection kind, then the
usual sharing mechanisms (clouds, etc) apply. I'd be interested in
seeing your ideas for how to do this. I've been focusing mostly on
straightening out the basic semantics, and I haven't gotten any other
feedback about metadata.
Its not that I want to associate specific metadata with ItemCollection.
Its that we need a generic way to associate ANY meta data with any
specific item collection.
More specifically, ItemCollections should not have a "calendarColor"
attribute because that's calendar-specific.
Alec
Ted
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
|
