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

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

Hi

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


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


But exactly how do you sort the view? Where is the sort order defined? 
Clicking on a column header of a list control should sort the bugs by 
ascending or descending priority. But all you have is a container of 
strings "low, medium, high, critical" and the alphabetical sort order is 
useless. It would be 'critical', 'high', 'low', 'medium'. So where would 
a generic list control get the true sort order from?

I think this is a case where the sort order is a fixed property of the 
container, not of a view of the container.

That is why I make a distinction between sort order imposed by a 
container and a sort order that depends on a view and can be different 
from user to user. I think we need both.

 >> So you think of every control as a view to the container?
 >
 >
 > I do.  Am I redefining the term?


No. I just wanted to make sure.

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


They might, if they can encapsulate all the attributes that the controls 
need.

 >> Another idea: The lit window library could introduce a 'filter' object,
 >> which is basically a view.


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


Sure. Filter behaviour would just be another data type and could be set 
like every other object, too.

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


Not at the moment. No. Creating your own iterator is the way to do this.

Hajo