[udig-devel] The Table View, previously known as Selection View

[Jody Garnett]

Myron Wu wrote:
> 1.)  It's been renamed to Table View to better reflect what it 
> actually does at the moment; it will always show all features in a 
> layer regardless of what's currently selected.
Good idea, lets get it to work and then we can add selection back in later.
> 2.)  It only shows the features of the topmost selected layer when 
> there's more than one layer selected.
> 3.)  There's no sorting at the moment and it displays features in 
> whatever order they come in from a given FeatureStore.
There are facilities to sort as part of "FeatureList", however they have 
not been used extensively yet. I would test first with shapefile and 
then a jdbc datastore.
> Technical:
> 1.)  It's currently implemented with a Tree and TreeViewer through 
> net.refractions.udig.ui.FeatureTableControl (reason why in a sec).
> 2.)  For increased responsiveness, we have it loading features into 
> the view in a separate thread through a DeferredTreeContentManager + 
> TreeViewer.  See http://www.ji.co.za/unplugged/?p=34 .
>
> Some questions we need to resolve for it to move forward:
> 1.)  How should we deal with multiple layers?  Seperate tables?  
> Groupings within a single table?  etc.
I think working on the current layer would be fine, you could also let 
the view be opened more then once if needed each tracking a different layer.
> 2.)  How should we deal with the current selection?  Highlighting?  
> Seperate tables or groupings again?
Highlighting, the concept of selecting entries in a table is already 
consistent. Please review the uDig requirements document.  I have a 
start on a formala editor I can show you that should also be available 
to set the selection.
> 1.)  Does it make sense to keep this as a Tree + TreeViewer?  This 
> depends on what we do about responsiveness and how we answer the two 
> questions above.
It should be displayed as a table, I think you can also use a virtual 
table to work on speed.
> 1.1.)  For responsiveness, I think we have a couple options.  What we 
> have now is less than ideal since it loads all features no matter 
> what, which is inefficient.  We can switch to an SWT.VIRTUAL table or 
> tree (added in 3.2M5), to load only features currently seen in the 
> view.  Anything else we can do here?
My understanding is you can do something like that now, without Eclipse 
3.2, that only requires the number of items be known. We should switch 
to FeatureList - so that both the number of features are known and they 
are available in a consistent order.  This interface was created 
specifically with TableView in mind, so any feedback you can get in 
before release will go straight into the API.

Cheers,
Jody