Home » Eclipse Projects » Nebula » CompositeTable has landed. :-)
|
| Re: CompositeTable has landed. :-) [message #14825 is a reply to message #14795] |
Sat, 21 October 2006 17:15   |
Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
David J. Orme wrote:
> - Use *any* SWT control anywhere in your grid's header or row
how does this compare with CTableTree's functionality. can i embed a
GEF viewer in a row? that's the primary use case i'm interested in.
i'm assuming that this means the row heights can be set individually.
how does CompositeTable compare to CTableTree in general?
thx,
al
|
|
|
| Re: CompositeTable has landed. :-) [message #14855 is a reply to message #14795] |
Sat, 21 October 2006 17:18 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
does CompositeTable use content providers ala JFace? if so, does it
support ITreePathContentProvider?
David J. Orme wrote:
> CompositeTable source code has just been committed to Nebula CVS with
> the following features:
>
> - Edit your grid visually using the Eclipse Visual Editor
> - Use *any* SWT control anywhere in your grid's header or row
> - Automatically edit in-place with zero extra code
> - Fully virtual -- only requests data that it actually displays
> - Insert / delete either programmatically or from the user interface.
> - Supports the new JFace Data Binding API (binding code in the JFace
> data binding examples plugin)
>
> In addition, an example Outlook(r)/PalmOS(r) calendar control has been
> submitted illustrating some of the more sophisticated things that can be
> done with this control.
>
> I'll be working with Chris to make a full download available as soon as
> possible. In the meantime, grab HEAD and try out CompositeTableTest and
> DayEditorTest to see how things work.
>
>
> Best regards,
>
> Dave Orme
|
|
|
| Re: CompositeTable has landed. :-) [message #14886 is a reply to message #14855] |
Sat, 21 October 2006 17:19 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
i see that there's no nebface viewer correspondong to CompositeTable, so
i'm assuming the answer to my questions are no and no.
Al Major wrote:
> does CompositeTable use content providers ala JFace? if so, does it
> support ITreePathContentProvider?
>
> David J. Orme wrote:
>> CompositeTable source code has just been committed to Nebula CVS with
>> the following features:
>>
>> - Edit your grid visually using the Eclipse Visual Editor
>> - Use *any* SWT control anywhere in your grid's header or row
>> - Automatically edit in-place with zero extra code
>> - Fully virtual -- only requests data that it actually displays
>> - Insert / delete either programmatically or from the user interface.
>> - Supports the new JFace Data Binding API (binding code in the JFace
>> data binding examples plugin)
>>
>> In addition, an example Outlook(r)/PalmOS(r) calendar control has been
>> submitted illustrating some of the more sophisticated things that can
>> be done with this control.
>>
>> I'll be working with Chris to make a full download available as soon
>> as possible. In the meantime, grab HEAD and try out
>> CompositeTableTest and DayEditorTest to see how things work.
>>
>>
>> Best regards,
>>
>> Dave Orme
|
|
|
| Re: CompositeTable has landed. :-) [message #14910 is a reply to message #14825] |
Sat, 21 October 2006 17:39 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
one difference appears to be tree functionality. i'm assuming
CompositeTable doesn't provide any. but is there an easy way to do
master/detail rows (basically a tree of depth 2)?
Al Major wrote:
> how does this compare with CTableTree's functionality. can i embed a
> GEF viewer in a row? that's the primary use case i'm interested in.
|
|
| |
| Re: CompositeTable has landed. :-) [message #15152 is a reply to message #14930] |
Sat, 21 October 2006 18:13 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
but that's an API for embedding a widget, one cell at at time (whichever
cell is being in-place-edited), correct? i just assumed it wasn't
appropriate for a table/tree that may have half or more of it's cells be
arbitrary widgets. if that's an incorrect assumption, i would definitely
consider that as an option.
Chris Gross wrote:
> It should be noted that you can use an TableEditor/TreeEditor to embed
> any widget in even the standard SWT Tree and Table.
>
> -Chris
>
>
> Al Major wrote:
>> David J. Orme wrote:
>>> - Use *any* SWT control anywhere in your grid's header or row
>>
>> how does this compare with CTableTree's functionality. can i embed
>> a GEF viewer in a row? that's the primary use case i'm interested in.
>>
>> i'm assuming that this means the row heights can be set individually.
>>
>> how does CompositeTable compare to CTableTree in general?
>>
>> thx,
>>
>> al
|
|
|
| Re: CompositeTable has landed. :-) [message #15182 is a reply to message #15152] |
Sat, 21 October 2006 18:30 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
plus, i do like JFace style model/view separation, so would want viewers
on top of the TreeEditor/Tree combo.
Al Major wrote:
> but that's an API for embedding a widget, one cell at at time (whichever
> cell is being in-place-edited), correct? i just assumed it wasn't
> appropriate for a table/tree that may have half or more of it's cells be
> arbitrary widgets. if that's an incorrect assumption, i would definitely
> consider that as an option.
>
> Chris Gross wrote:
>> It should be noted that you can use an TableEditor/TreeEditor to embed
>> any widget in even the standard SWT Tree and Table.
>>
>> -Chris
>>
>>
>> Al Major wrote:
>>> David J. Orme wrote:
>>>> - Use *any* SWT control anywhere in your grid's header or row
>>>
>>> how does this compare with CTableTree's functionality. can i
>>> embed a GEF viewer in a row? that's the primary use case i'm
>>> interested in.
>>>
>>> i'm assuming that this means the row heights can be set
>>> individually.
>>>
>>> how does CompositeTable compare to CTableTree in general?
>>>
>>> thx,
>>>
>>> al
|
|
| |
| Re: CompositeTable has landed. :-) [message #15247 is a reply to message #15214] |
Sat, 21 October 2006 20:02 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
if this works as the snippet implies, one option for me would be to
modify the standard JFace viewer so that it'll
a) provide a model that allows a representation of arbitrary widgets in
rows, kinda like CTableTreeViewer
b) use the ***Editor classes within this modified viewer to implement
the arbitrary widgets using the standard Tree controls
c) change the row-height of TreeItem (on a first glance at the code,
this actually seems to be the only thing that the current design makes
difficult).
this seems a bit like re-inventing CTableTreeViewer without the
tree-in-every-cell feature (which i don't need). but since that viewer
needs to be modified to support my use-case (ITreePathContentProvider),
this may actually be the easiest option for me.
however, this is such a common use-case (i think) that it begs to be
abstracted. it probably should be in JFace to begin with. or somewhere
else where it can be re-used.
al
Chris Gross wrote:
> The base SWT TableEditor/TreeEditor classes can be specifically
> activated or active all the time. Its up to you. See the following SWT
> snippet:
>
> http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.ecli pse.swt.snippets/src/org/eclipse/swt/snippets/Snippet126.jav a
>
>
> Regarding JFace viewers, I believe you can use a viewer and still create
> and use a regular SWT TableEditor. JFace viewers also have a paradigm
> for using its own cell editors which are typically triggered by clicking
> on the cell. I'm not sure if JFace has a way to keep an editor active.
>
> -Chris
>
> Al Major wrote:
>> plus, i do like JFace style model/view separation, so would want
>> viewers on top of the TreeEditor/Tree combo.
>>
>> Al Major wrote:
>>> but that's an API for embedding a widget, one cell at at time
>>> (whichever cell is being in-place-edited), correct? i just assumed it
>>> wasn't appropriate for a table/tree that may have half or more of
>>> it's cells be arbitrary widgets. if that's an incorrect assumption, i
>>> would definitely consider that as an option.
>>>
>>> Chris Gross wrote:
>>>> It should be noted that you can use an TableEditor/TreeEditor to
>>>> embed any widget in even the standard SWT Tree and Table.
>>>>
>>>> -Chris
>>>>
>>>>
>>>> Al Major wrote:
>>>>> David J. Orme wrote:
>>>>>> - Use *any* SWT control anywhere in your grid's header or row
>>>>>
>>>>> how does this compare with CTableTree's functionality. can i
>>>>> embed a GEF viewer in a row? that's the primary use case i'm
>>>>> interested in.
>>>>>
>>>>> i'm assuming that this means the row heights can be set
>>>>> individually.
>>>>>
>>>>> how does CompositeTable compare to CTableTree in general?
>>>>>
>>>>> thx,
>>>>>
>>>>> al
|
|
|
| Re: CompositeTable has landed. :-) [message #15280 is a reply to message #14825] |
Sat, 21 October 2006 20:41 |
 Dave Orme
Messages: 424
Registered: July 2009 |
Senior Member |
|
|
Al Major wrote:
> David J. Orme wrote:
>> - Use *any* SWT control anywhere in your grid's header or row
>
> how does this compare with CTableTree's functionality. can i embed a
> GEF viewer in a row? that's the primary use case i'm interested in.
I believe that CTableTree is lightweight. CompositeTable works by
pasting together existing SWT controls to look and behave like a table.
> i'm assuming that this means the row heights can be set individually.
Currently all rows must be the same height. If you need flexibility
here, please file a bug or better yet, contribute a patch. :-)
> how does CompositeTable compare to CTableTree in general?
CompositeTable makes no attempts to be a tree and it's best to think of
it as like a *really* powerful tabular layout manager because it
fundamentally works with other controls that you supply.
The advantage is that you get complete flexibility for how the users
will interact with your table as well as complete flexibility about
mixing and/or matching lightweight and heavyweight controls inside your
table. The disadvantage is that a highly-optimized lightweight control
will draw and, resize, and scroll somewhat faster.
To see both the advantages and disadvantages in action at once, try
running the DayEditorTest demo, which implements an Outlook-like work
week calendar control. It really powerful and looks nice, but when you
load a lot of data into it, there are a few visible artifacts when you
scroll where you can see the layout managers delegating layout semantics
to all of the embedded controls.
DayEditor is an extreme example both of how graphical you can get with
CompositeTable and also pushes the limits of what you can do nicely with
it performance-wise, so it's a pretty good example to study.
Regards,
Dave Orme
Regards,
Dave Orme
|
|
| | | |
| Re: CompositeTable has landed. :-) [message #15411 is a reply to message #15378] |
Sun, 22 October 2006 03:58 |
| Eclipse User |
|
|
|
Originally posted by: alnospammajor.noboxspamspoon.com
hmm. data binding isn't particularly important in this case.
architecture/API similarity/correspondence with other JFace viewers is
desirable. but i'll take a look at the actual CompositeTable code before
i comment further.
David J. Orme wrote:
> Al Major wrote:
>> does CompositeTable use content providers ala JFace? if so, does it
>> support ITreePathContentProvider?
>
> CompositeTable uses a concept similar to JFace content providers by
> default (since it's virtual). Again, because CompositeTable is virtual,
> it is actually impossible to use CompositeTable in any way other than
> via some sort of MVC pattern--either using CompositeTable's native API
> or via data binding.
>
> CompositeTable's native API is intentionally designed to be conceptually
> similar to JFace, but because of the requirement to be able to put any
> kind of control anywhere in a row using any layout manager, the API
> necessarily isn't exactly the same as JFace.
>
> In addition, CompositeTable supports the new JFace data binding API
> right now. (We actually have deployed CompositeTable in a 2 million
> plus line enterprise application using data binding as the MVC layer.)
>
> So CompositeTable supports a nice MVC separation of concerns either way.
>
>
> Best regards,
>
> Dave Orme
|
|
|
| Re: CompositeTable has landed. :-) [message #15444 is a reply to message #14910] |
Sun, 22 October 2006 20:34 |
Jeremy Dowdall
Messages: 181
Registered: July 2009 |
Senior Member |
|
|
> ...is there an easy way to do
> master/detail rows (basically a tree of depth 2)?
Master/Detail rows is what caused CTableTree to be created in the first
place, though maybe we're talking about different things here.
A master/detail block, as one might create using the Forms toolkit, has
a table on one side and a detail composite on the other. As the user
selects an item from the table, the appropriate info is filled in, and
is editable in, the child controls of the detail composite.
see the pic most of the way down this page:
http://www.eclipse.org/articles/Article-Forms/article.html
When using the CTableTree, each cell's title area effectively creates
the master table but rather than having a separate detail composite to
the side, it is in the child area of the cell (which can now span the
width of the table width if necessary).
see in the first pic's upper left, "Contacts", view part:
http://www.aspencloud.com/screenshots.php
Is there a reason you do not use the child area of the CTableTreeCell?
|
|
| | | | | | | | | | | | |
| Re: CompositeTable has landed. :-) [message #567305 is a reply to message #15214] |
Sat, 21 October 2006 20:02 |
Al Major
Messages: 72
Registered: July 2009 |
Member |
|
|
if this works as the snippet implies, one option for me would be to
modify the standard JFace viewer so that it'll
a) provide a model that allows a representation of arbitrary widgets in
rows, kinda like CTableTreeViewer
b) use the ***Editor classes within this modified viewer to implement
the arbitrary widgets using the standard Tree controls
c) change the row-height of TreeItem (on a first glance at the code,
this actually seems to be the only thing that the current design makes
difficult).
this seems a bit like re-inventing CTableTreeViewer without the
tree-in-every-cell feature (which i don't need). but since that viewer
needs to be modified to support my use-case (ITreePathContentProvider),
this may actually be the easiest option for me.
however, this is such a common use-case (i think) that it begs to be
abstracted. it probably should be in JFace to begin with. or somewhere
else where it can be re-used.
al
Chris Gross wrote:
> The base SWT TableEditor/TreeEditor classes can be specifically
> activated or active all the time. Its up to you. See the following SWT
> snippet:
>
> http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.ecli pse.swt.snippets/src/org/eclipse/swt/snippets/Snippet126.jav a
>
>
> Regarding JFace viewers, I believe you can use a viewer and still create
> and use a regular SWT TableEditor. JFace viewers also have a paradigm
> for using its own cell editors which are typically triggered by clicking
> on the cell. I'm not sure if JFace has a way to keep an editor active.
>
> -Chris
>
> Al Major wrote:
>> plus, i do like JFace style model/view separation, so would want
>> viewers on top of the TreeEditor/Tree combo.
>>
>> Al Major wrote:
>>> but that's an API for embedding a widget, one cell at at time
>>> (whichever cell is being in-place-edited), correct? i just assumed it
>>> wasn't appropriate for a table/tree that may have half or more of
>>> it's cells be arbitrary widgets. if that's an incorrect assumption, i
>>> would definitely consider that as an option.
>>>
>>> Chris Gross wrote:
>>>> It should be noted that you can use an TableEditor/TreeEditor to
>>>> embed any widget in even the standard SWT Tree and Table.
>>>>
>>>> -Chris
>>>>
>>>>
>>>> Al Major wrote:
>>>>> David J. Orme wrote:
>>>>>> - Use *any* SWT control anywhere in your grid's header or row
>>>>>
>>>>> how does this compare with CTableTree's functionality. can i
>>>>> embed a GEF viewer in a row? that's the primary use case i'm
>>>>> interested in.
>>>>>
>>>>> i'm assuming that this means the row heights can be set
>>>>> individually.
>>>>>
>>>>> how does CompositeTable compare to CTableTree in general?
>>>>>
>>>>> thx,
>>>>>
>>>>> al
|
|
|
| Re: CompositeTable has landed. :-) [message #567320 is a reply to message #14825] |
Sat, 21 October 2006 20:41 |
Dave Orme
Messages: 424
Registered: July 2009 |
Senior Member |
|
|
Al Major wrote:
> David J. Orme wrote:
>> - Use *any* SWT control anywhere in your grid's header or row
>
> how does this compare with CTableTree's functionality. can i embed a
> GEF viewer in a row? that's the primary use case i'm interested in.
I believe that CTableTree is lightweight. CompositeTable works by
pasting together existing SWT controls to look and behave like a table.
> i'm assuming that this means the row heights can be set individually.
Currently all rows must be the same height. If you need flexibility
here, please file a bug or better yet, contribute a patch. :-)
> how does CompositeTable compare to CTableTree in general?
CompositeTable makes no attempts to be a tree and it's best to think of
it as like a *really* powerful tabular layout manager because it
fundamentally works with other controls that you supply.
The advantage is that you get complete flexibility for how the users
will interact with your table as well as complete flexibility about
mixing and/or matching lightweight and heavyweight controls inside your
table. The disadvantage is that a highly-optimized lightweight control
will draw and, resize, and scroll somewhat faster.
To see both the advantages and disadvantages in action at once, try
running the DayEditorTest demo, which implements an Outlook-like work
week calendar control. It really powerful and looks nice, but when you
load a lot of data into it, there are a few visible artifacts when you
scroll where you can see the layout managers delegating layout semantics
to all of the embedded controls.
DayEditor is an extreme example both of how graphical you can get with
CompositeTable and also pushes the limits of what you can do nicely with
it performance-wise, so it's a pretty good example to study.
Regards,
Dave Orme
Regards,
Dave Orme
|
|
| | | | |
| Re: CompositeTable has landed. :-) [message #567469 is a reply to message #14910] |
Sun, 22 October 2006 20:34 |
Jeremy Dowdall
Messages: 181
Registered: July 2009 |
Senior Member |
|
|
> ...is there an easy way to do
> master/detail rows (basically a tree of depth 2)?
Master/Detail rows is what caused CTableTree to be created in the first
place, though maybe we're talking about different things here.
A master/detail block, as one might create using the Forms toolkit, has
a table on one side and a detail composite on the other. As the user
selects an item from the table, the appropriate info is filled in, and
is editable in, the child controls of the detail composite.
see the pic most of the way down this page:
http://www.eclipse.org/articles/Article-Forms/article.html
When using the CTableTree, each cell's title area effectively creates
the master table but rather than having a separate detail composite to
the side, it is in the child area of the cell (which can now span the
width of the table width if necessary).
see in the first pic's upper left, "Contacts", view part:
http://www.aspencloud.com/screenshots.php
Is there a reason you do not use the child area of the CTableTreeCell?
|
|
| | | | |
Goto Forum:
Current Time: Fri Apr 19 19:57:15 GMT 2024
Powered by FUDForum. Page generated in 0.07075 seconds |
] 
Search
Help
Register
Login
Home
