The JavaFX approach is interesting, but I suspect there would be hidden complexities. We'd need to add UI event processing methods to the Renderer interface, which isn't consistent with the nature of a renderer. Also, as you noted, Pivot provides TablePane and row editors for this purpose. To some of the specific examples below:
> - a link button, to navigate to detail panes I see this fairly often in HTML tables (more like TablePane), but not so much in more traditional data-driven table applications (e.g. file browser, mail client - these are more like TableView). > - an expander, to show additional row details Even if a rollup could be nested in a TableView, there are other complexities (like how to model which rows should be visible/hidden). For this type of UI, I might try putting a set of TableViews in Rollup containers within a vertical box pane. > - a movie component, displaying a YouTube video (yes, I'm serious, and JavaFX > is capable of this) While interesting, there's not a strong use case for this. TableView is optimized for displaying a large volume of data. You are not likely to want to display thousands of videos at a time. This sounds like a use case for TablePane. > - any input component (such as TextInput etc) that you want to show > immediately without forcing the user to enter edit mode explicitly As I mentioned in another post, I have done this by showing a popup window over the current row. So far, this approach has worked very well. You can also trigger an editor as needed - your app doesn't have to rely on the edit trigger that is built into the skin. Greg On Apr 30, 2010, at 6:27 AM, Noel Grandin wrote: > Hi > > Dirk Möbius wrote: >> Noel Grandin <[email protected]> wrote: >>> That is the same approach Swing uses. >> >> No it's not, because Swing doesn't pass any events to the cell >> renderer. (Neither does Pivot.) >> > Yes it is. This is exactly how JTable works. > >>> And it has the same problems - getting events into and out of the cell >>> is tricky and means that the cell component needs various bits of >>> tweaking to cope properly with things like focus gain/release. >> >> True, it can be tricky. But the tricky part has been dealt with by the >> JavaFX team, so it is not left to the framework user. >> > Even when the framework "deals with it", it leaves behind a variety of > interesting little constraints and tricks for the developer to discover. > Note how hard it is insert custom components into a JTable and get all > of the focussing and other little details completely correct. And then > someone tries to implement something like alternate-row-striping on the > JTable, and it blows up the assumptions that the custom component was > operating under. > > >>> I'm in two minds about this. Personally, I try where-ever possible to >>> avoid using the Swing components that do this (JTable) in favour of >>> putting real components into real containers. >>> >>> However, there are a very few use-cases (editable tables containing very >>> large numbers of rows) that can benefit from this approach. >> >> I think using components in tables is a pretty common use case in >> modern applications. Examples: >> - a link button, to navigate to detail panes >> - an expander, to show additional row details >> - a movie component, displaying a YouTube video (yes, I'm serious, and >> JavaFX is capable of this) >> - any input component (such as TextInput etc) that you want to show >> immediately without forcing the user to enter edit mode explicitly >> >> Dirk. >> > > True, which is why Pivot has TablePane. > Maybe it's not perfect, because it forces you to use Label for a lot of > things, and it's memory consumption is higher, but it's also very > predictable in terms of how the components interact with their parent > container. > > Like I said, there is maybe a need for this, I'm just not convinced that > it is something that the core components need to support. > > Regards, Noel. >
