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

[yrs90 <yr...@ya...>]

> 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.

Perhaps part of what leads to the ambiguity over where to sort is that the
wx controls store a copy of the data.  So, for example, the wxListCtrl can
sort its contents independent of the source data.  Perhaps container or
iterator base ordering is more an issue in a lightweight control.

My initial reaction is that imposing external source-data/iterator ordering
on the control may either conflict with or reinvent the control management.
Perhaps there are some rules that just apply to the control (on column
click, sort by column) while other rules deal with the moving of data to and
from the control (on delete key, delete element from container). 

In your example, perhaps I don't understand the distinction you are making.
The priority is an attribute of the object by which the view can sort.  It
might just as easily sort by another attribute like the date.  Perhaps one
view has a priority sorted list while another shows a histogram of bugs by
priority for each day.


> 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.

This sounds useful.

> 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.

Perhaps the user could decide the cost by using a property 'Sorted' that
would use the costlier sorted iterator rather than the native stl iterator.


> 
> >>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?

In the case of wxListCtrl, the sort criteria can be bound to the control.
Now the next question is how sort criteria can be described by a rule.  I am
not sure.

> So you think of every control as a view to the container? 

I do.  Am I redefining the term?

> Where and how do you save the view attributes?

In some cases the controls have provisions to save these attributes.  When
they don't, I am not sure.  Will sortable iterators (which I've started to
think are a good idea) help address this problem?

> 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.

How would selective display be achieved without using a filter object? These
seem like a necessary feature. Could filter behavior be rules based too?

> 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.

Those filter rules would require just about as much customization as the
columnheader property. On the other hand, it would make it possible to
dynamically alter the number of columns that were displayed. This sounds
useful.

Actually I was wondering about filtering earlier too. I guess I need to
implement a new iterator for my container in order to achieve filtering,
right?  I can't create a rule that accesses a container via function calls?

Regard,
Joel


---
[This E-mail scanned for viruses by Declude Virus]