Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 340568

Summary:	[client] Create generic tree table
Product:	[ECD] Orion	Reporter:	Malgorzata Janczarska <malgorzata.tomczyk>
Component:	Client	Assignee:	Malgorzata Janczarska <malgorzata.tomczyk>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	susan, Szymon.Brandys
Version:	0.2
Target Milestone:	0.2
Hardware:	PC
OS:	All
Whiteboard:
Bug Depends on:
Bug Blocks:	338226, 342247, 342248

Description Malgorzata Janczarska

2011-03-21 10:07:55 EDT

There are several places in application when we need table or tree-table:
1. Manage users (table)
2. Git repositories (table now, tree-table in future)
3. Git log (table)
4. Git push/fetch/merge view
and of cause
5. File explorer (tree-table)

 To avoid code multiplication and styling differences we should create a generic explorer that would have templates for explorer, model and renderer.
 I create generic-explorer.js in client.core and I used it in git repositories UI. I created two templates for renderer: one implements the render method and only allows user only to return a content of each cell. The other one is more flexible and allows user to implement the method rendering the whole row. It provides function that generate some common elements, like actions, or expand node, that can be called in desired cell.

Comment 1 Susan McCourt

2011-03-21 15:50:48 EDT

this would also be useful so that if we wish to convert everything to another widget (such as dojox tree grid), we could do it in one place.

Comment 2 Susan McCourt

2011-04-04 18:36:43 EDT

Finally gotta look at this as I was working on bug 334195. I'm assuming your plan is to change explorer-table to use this new stuff? I was imagining what that would look like, and I think I want to nitpick on names.

I don't like prefixes like "Generic" or "Simple" because they don't really tell me what this thing does for me. The abstractions arose out of very specific use cases, so I'd like names that really help explain the abstractions.

For GenericExplorer, it seems like you are providing a common explorer for navigating location-based items. What about just calling it "Explorer" as that kind of implies hierarchical file exploring. I tried to think of other names (like WorkspaceExplorer or FileExplorer) but really those are too specific. "HierarchicalLocationExplorer" is more precise, but too long! Maybe just use "Explorer." It's nice and terse.

SimpleTreeTableModel seems like scaffolding for calling fetch methods and hooking up children pointers, generating location-based ids. Maybe just call it "ExplorerModel"??? Since it is designed to go with the above explorer?

GenericTableRenderer is providing selection service check marks, command-service based action columns, and common icons, etc. Maybe "SelectionRenderer"?? That seems to be its main purpose. There is no location-based assumptions in this code, so "ExplorerRenderer" didn't seem right, seems like this could work for any table tree that needed selection.

For all the above, I suggest keep them in a file called explorer.js (rather than generic-explorer.js), knowing that it's possible the last class would get pulled out into something separate if we ever need the selection/action behavior for non-location based models.

But SimpleTreeTableRenderer seems different than the three above. It's providing common scaffolding that all renders would want. Perhaps it should be moved into treetable.js???

Comment 3 Malgorzata Janczarska

2011-04-06 13:39:19 EDT

I incorporated Susan's comments about names. I had to change name of eclipse.Explorer in explorer-table.js so that it doesn't clash with the name of former GenericExplorer.
I've moved explorer-table to use the generic mechanism.

Comment 4 Malgorzata Janczarska

2011-04-08 08:45:02 EDT