[litwindow-users] Re: <map> as container

[Hajo K. <mai...@ha...>]

yrs90 wrote:
>>Is the sort order an inherent attribute of the 
>>collection? Or is the sort order just a 'view' to the collection, 
>>imposed by the user.... So, should sorting be part of the container 
>>or not?
> 
> 
> I had assumed that sort order should be part of the view rather than part of
> the container.  Multiple views of data are not uncommon.  Multiple views
> probably require that sort order be independent of the container.

Take the following problem: You are writing a bug tracking application 
and are offering the user a 'priority' enumeration: low, medium, high, 
critical. You also want to let the user modify this list.

The sort order here is implied by the semantics of the object, not by a 
view.

>>Iterators otoh will be short-lived objects used to access and iterate 
>>the container. Their sort order can be changed without changing the 
>>actual sort order of the underlying container.
> 
> 
> This is an interesting perspective.  I had assumed that sorting would be
> handled by the view itself rather than by an iterator.  Is there a way to
> provide sorted iterators efficiently?

I don't know yet, but why not. These iterators would not sort the 
underlying objects in the container itself, of course. Rather they would 
be a sorted vector of pointers to the objects. This is the same approach 
that ADO(.NET) uses with ADO record sets. You load a recordset into 
memory (-> container) and then get a cursor (-> iterator). The nice 
thing is you can have more than one cursor and can specify a sort order 
for each cursor.

The lit window container abstraction will then of course be a lot 
higher-level than the STL. And performance will not always be as good as 
the STL.

>>This high-level container might even contain more than one 'index'.
> 
> 
> I don't see why it is desirable to have more than one index to a given
> container element.  Well, that is unless you mean to have the index not only
> indicate the item, but also the particular sorting that was used.  But that
> seems unnecessary since element ordering is available from the view (or
> through a sortable iterator).

What exactly is a view?

Imagine a container and a program that has more than one list control 
that is being connected to the container. How would you solve the 
problem that each list control can have a different sort order?



> Restricting to a single association between a control and a container is too
> constraining for a general framework, I think.  Although, so long as (a)
> only one control could access a given container at any given time and (b) a
> container could notify all bound controls when change had occurred, then I
> think it would work for multiple controls bound to a single container too.

I agree.

>>Idea 1:
>>Insertion / deletion is being handled by the container itself. 
>>Interested objects are being notified.
> 
> The only troublesome part of this is that it takes a bit of work for a
> control to gain access to its bound container.  I expect the access
> mechanism could hidden, which would make this the more versatile approach.
> For one thing, a deletion from a view might be achieved by setting a
> container element attribute to "hidden".

So you think of every control as a view to the container? Where and how 
do you save the view attributes?

Another idea: The lit window library could introduce a 'filter' object, 
which is basically a view. This is an idea that pops up every now and 
then. A filter would take an accessor (aggregate or container), modify 
it in specific ways and represent this modification as an accessor 
itself. You could bind your control to a filter and bind the filter to a 
container. Filter would then essentially become a view. The control 
could change the filter's sort order, perhaps there really could be a 
filter expression so you could display only specific parts of containers.

Another example of where filters where handy would be the column 
headers. Currently you have the 'columnheader' property. But you could 
filter the aggregates, remove unwanted members from the aggregate and 
change the names of the other members and the order through a filter.

Hajo