| Brainstorming: grid as a spreadsheet [message #46350] |
Fri, 11 January 2008 16:52  |
Eclipse User |
|
|
|
Originally posted by: sf.tragwerk-dresden.de
Hi all,
current table oriented widgets and their JFace-Viewers are all row
oriented. That means that the number of columns is fixed and each row
represents an (Business-)Object of the same type. This is ok for the
most data-centric applications, where you can focus on a (one
dimensional) collection of things.
But I think there *is* a need for viewers which are able to map a 2
dimensional oriented data-model to a table. So the number of rows *and*
the number columns should depend on the model's state. I think of
concerns in science ore related sectors. At least I have a need for it
(civil engineering).
I think Grid is a prefered Widget for that.
Currently I experimented myself with the existing Viewers and I am sure
I will get a solution - somehow.
But if there is real need from the comunity for that we need a more
professional solution.
Maybe Tom Schindl could give his 2 Cents as well as Chris Gross or Boris
Bokowski.
What is needed most is
a) a ContentProvider which does something like
public Object[][] getElements(Object input)
b) a Viewer which can create and dispose rows and columns on refresh()
c) a DataBinding support to observe (input-)model structure changes to
refresh the viewer
d) a cell oriented DataBinding support for CellEditors
Sebastian
|
|
|
|
| Re: Brainstorming: grid as a spreadsheet [message #46470 is a reply to message #46382] |
Mon, 14 January 2008 08:50  |
| Eclipse User |
|
|
|
Originally posted by: sf.tragwerk-dresden.de
Tom, thank you for considering this.
1)
I am afraid, a structural change can not happen only on setInput().
Like in a one dimensional data structure, the number of items in a list
can change, but it is always the same list I want to show (= input).
I think it is a bad practise to manually set the same list as a new
input again when a structural change happens.
2)
.... [from snippet 13]
protected void initializeCellEditorValue(CellEditor cellEditor,
ViewerCell cell) {
Object modelElement = cell.getElement();
....
cell.getElements() returns the model object for the current *row*.
What I meant is, that each *cell* should have its own representing model
object. You are right, this is actually not a databinding concern but it
is related.
All my current approaches to get a 2 dimensional table to work mixed up
the current layers.
Sebastian
Tom Schindl schrieb:
> Hi,
>
> A few comments are below (although I need to think about this a bit
more :-) .
>
> Sebastian Fuchs schrieb:
>> Hi all,
>>
>> current table oriented widgets and their JFace-Viewers are all row
oriented. That means that the number of columns is fixed and each row
represents an (Business-)Object of the same type. This is ok for the
most data-centric applications, where you can focus on a (one
dimensional) collection of things.
>>
>> But I think there *is* a need for viewers which are able to map a 2
dimensional oriented data-model to a table. So the number of rows *and*
the number columns should depend on the model's state. I think of
concerns in science ore related sectors. At least I have a need for it
(civil engineering).
>>
>> I think Grid is a prefered Widget for that.
>> Currently I experimented myself with the existing Viewers and I am
sure I will get a solution - somehow.
>> But if there is real need from the comunity for that we need a more
professional solution.
>>
>> Maybe Tom Schindl could give his 2 Cents as well as Chris Gross or
Boris Bokowski.
>>
>> What is needed most is
>>
>> a) a ContentProvider which does something like
>> public Object[][] getElements(Object input)
>>
>> b) a Viewer which can create and dispose rows and columns on refresh()
>>
>> c) a DataBinding support to observe (input-)model structure changes
to refresh the viewer
>
> If we could come together that a structural change to the 2 dimension
can only happen when a new input is set this is already supported by the
current databinding lib (see ObservableListContentProvider).
>
>>
>> d) a cell oriented DataBinding support for CellEditors
>>
>
> Already reality but not part of the databinding framework but the
changes in the JFace-API in 3.3 added the needed hooks ;-)
>
>
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.e xamples.databinding/src/org/eclipse/jface/examples/databindi ng/snippets/Snippet013TableViewerEditing.java?view=markup
>
> I'll comment more on these and other points after having thought more
about it.
>
> Tom
>
>
|
|
|
| Re: Brainstorming: grid as a spreadsheet [message #46501 is a reply to message #46470] |
Mon, 14 January 2008 13:43 |
 Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Would it be possible for you to share some piece of code (preferably a
snippet) so that I get a starting point and see the problems? Maybe I
can come up with a solution then :-)
Tom
Sebastian Fuchs schrieb:
> Tom, thank you for considering this.
>
> 1)
> I am afraid, a structural change can not happen only on setInput().
> Like in a one dimensional data structure, the number of items in a list
> can change, but it is always the same list I want to show (= input).
> I think it is a bad practise to manually set the same list as a new
> input again when a structural change happens.
>
> 2)
> ... [from snippet 13]
> protected void initializeCellEditorValue(CellEditor cellEditor,
> ViewerCell cell) {
> Object modelElement = cell.getElement();
> ...
> cell.getElements() returns the model object for the current *row*.
> What I meant is, that each *cell* should have its own representing model
> object. You are right, this is actually not a databinding concern but it
> is related.
>
> All my current approaches to get a 2 dimensional table to work mixed up
> the current layers.
>
> Sebastian
>
>
> Tom Schindl schrieb:
> > Hi,
> >
> > A few comments are below (although I need to think about this a bit
> more :-) .
> >
> > Sebastian Fuchs schrieb:
> >> Hi all,
> >>
> >> current table oriented widgets and their JFace-Viewers are all row
> oriented. That means that the number of columns is fixed and each row
> represents an (Business-)Object of the same type. This is ok for the
> most data-centric applications, where you can focus on a (one
> dimensional) collection of things.
> >>
> >> But I think there *is* a need for viewers which are able to map a 2
> dimensional oriented data-model to a table. So the number of rows *and*
> the number columns should depend on the model's state. I think of
> concerns in science ore related sectors. At least I have a need for it
> (civil engineering).
> >>
> >> I think Grid is a prefered Widget for that.
> >> Currently I experimented myself with the existing Viewers and I am
> sure I will get a solution - somehow.
> >> But if there is real need from the comunity for that we need a more
> professional solution.
> >>
> >> Maybe Tom Schindl could give his 2 Cents as well as Chris Gross or
> Boris Bokowski.
> >>
> >> What is needed most is
> >>
> >> a) a ContentProvider which does something like
> >> public Object[][] getElements(Object input)
> >>
> >> b) a Viewer which can create and dispose rows and columns on refresh()
> >>
> >> c) a DataBinding support to observe (input-)model structure changes
> to refresh the viewer
> >
> > If we could come together that a structural change to the 2 dimension
> can only happen when a new input is set this is already supported by the
> current databinding lib (see ObservableListContentProvider).
> >
> >>
> >> d) a cell oriented DataBinding support for CellEditors
> >>
> >
> > Already reality but not part of the databinding framework but the
> changes in the JFace-API in 3.3 added the needed hooks ;-)
> >
> >
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.e xamples.databinding/src/org/eclipse/jface/examples/databindi ng/snippets/Snippet013TableViewerEditing.java?view=markup
>
> >
> > I'll comment more on these and other points after having thought more
> about it.
> >
> > Tom
> >
> >
>
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: Brainstorming: grid as a spreadsheet [message #46631 is a reply to message #46501] |
Tue, 15 January 2008 08:57 |
| Eclipse User |
|
|
|
Originally posted by: sf.tragwerk-dresden.de
Today's approach looks promising.
I am about wrapping the existing viewers.
Thank you so long.
I will raise a new thread when I am forcing problems.
Sebastian
Tom Schindl schrieb:
> Would it be possible for you to share some piece of code (preferably a
> snippet) so that I get a starting point and see the problems? Maybe I
> can come up with a solution then :-)
>
> Tom
|
|
|
| Re: Brainstorming: grid as a spreadsheet [message #46652 is a reply to message #46501] |
Tue, 15 January 2008 11:20 |
| Eclipse User |
|
|
|
Originally posted by: sf.tragwerk-dresden.de
Tom,
it seems to work.
If you are interested in the code please let me know.
It's too complex to show it in a simple snippet.
Furthermore my comments are all in German.
sf [at] tragwerk-dresden.de
Sebastian
|
|
|
|
|
|
| Re: Brainstorming: grid as a spreadsheet [message #587627 is a reply to message #46382] |
Mon, 14 January 2008 08:50 |
Sebastian Fuchs
Messages: 97
Registered: July 2009 |
Member |
|
|
Tom, thank you for considering this.
1)
I am afraid, a structural change can not happen only on setInput().
Like in a one dimensional data structure, the number of items in a list
can change, but it is always the same list I want to show (= input).
I think it is a bad practise to manually set the same list as a new
input again when a structural change happens.
2)
.... [from snippet 13]
protected void initializeCellEditorValue(CellEditor cellEditor,
ViewerCell cell) {
Object modelElement = cell.getElement();
....
cell.getElements() returns the model object for the current *row*.
What I meant is, that each *cell* should have its own representing model
object. You are right, this is actually not a databinding concern but it
is related.
All my current approaches to get a 2 dimensional table to work mixed up
the current layers.
Sebastian
Tom Schindl schrieb:
> Hi,
>
> A few comments are below (although I need to think about this a bit
more :-) .
>
> Sebastian Fuchs schrieb:
>> Hi all,
>>
>> current table oriented widgets and their JFace-Viewers are all row
oriented. That means that the number of columns is fixed and each row
represents an (Business-)Object of the same type. This is ok for the
most data-centric applications, where you can focus on a (one
dimensional) collection of things.
>>
>> But I think there *is* a need for viewers which are able to map a 2
dimensional oriented data-model to a table. So the number of rows *and*
the number columns should depend on the model's state. I think of
concerns in science ore related sectors. At least I have a need for it
(civil engineering).
>>
>> I think Grid is a prefered Widget for that.
>> Currently I experimented myself with the existing Viewers and I am
sure I will get a solution - somehow.
>> But if there is real need from the comunity for that we need a more
professional solution.
>>
>> Maybe Tom Schindl could give his 2 Cents as well as Chris Gross or
Boris Bokowski.
>>
>> What is needed most is
>>
>> a) a ContentProvider which does something like
>> public Object[][] getElements(Object input)
>>
>> b) a Viewer which can create and dispose rows and columns on refresh()
>>
>> c) a DataBinding support to observe (input-)model structure changes
to refresh the viewer
>
> If we could come together that a structural change to the 2 dimension
can only happen when a new input is set this is already supported by the
current databinding lib (see ObservableListContentProvider).
>
>>
>> d) a cell oriented DataBinding support for CellEditors
>>
>
> Already reality but not part of the databinding framework but the
changes in the JFace-API in 3.3 added the needed hooks ;-)
>
>
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.e xamples.databinding/src/org/eclipse/jface/examples/databindi ng/snippets/Snippet013TableViewerEditing.java?view=markup
>
> I'll comment more on these and other points after having thought more
about it.
>
> Tom
>
>
|
|
|
| Re: Brainstorming: grid as a spreadsheet [message #587633 is a reply to message #46470] |
Mon, 14 January 2008 13:43 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Would it be possible for you to share some piece of code (preferably a
snippet) so that I get a starting point and see the problems? Maybe I
can come up with a solution then :-)
Tom
Sebastian Fuchs schrieb:
> Tom, thank you for considering this.
>
> 1)
> I am afraid, a structural change can not happen only on setInput().
> Like in a one dimensional data structure, the number of items in a list
> can change, but it is always the same list I want to show (= input).
> I think it is a bad practise to manually set the same list as a new
> input again when a structural change happens.
>
> 2)
> ... [from snippet 13]
> protected void initializeCellEditorValue(CellEditor cellEditor,
> ViewerCell cell) {
> Object modelElement = cell.getElement();
> ...
> cell.getElements() returns the model object for the current *row*.
> What I meant is, that each *cell* should have its own representing model
> object. You are right, this is actually not a databinding concern but it
> is related.
>
> All my current approaches to get a 2 dimensional table to work mixed up
> the current layers.
>
> Sebastian
>
>
> Tom Schindl schrieb:
> > Hi,
> >
> > A few comments are below (although I need to think about this a bit
> more :-) .
> >
> > Sebastian Fuchs schrieb:
> >> Hi all,
> >>
> >> current table oriented widgets and their JFace-Viewers are all row
> oriented. That means that the number of columns is fixed and each row
> represents an (Business-)Object of the same type. This is ok for the
> most data-centric applications, where you can focus on a (one
> dimensional) collection of things.
> >>
> >> But I think there *is* a need for viewers which are able to map a 2
> dimensional oriented data-model to a table. So the number of rows *and*
> the number columns should depend on the model's state. I think of
> concerns in science ore related sectors. At least I have a need for it
> (civil engineering).
> >>
> >> I think Grid is a prefered Widget for that.
> >> Currently I experimented myself with the existing Viewers and I am
> sure I will get a solution - somehow.
> >> But if there is real need from the comunity for that we need a more
> professional solution.
> >>
> >> Maybe Tom Schindl could give his 2 Cents as well as Chris Gross or
> Boris Bokowski.
> >>
> >> What is needed most is
> >>
> >> a) a ContentProvider which does something like
> >> public Object[][] getElements(Object input)
> >>
> >> b) a Viewer which can create and dispose rows and columns on refresh()
> >>
> >> c) a DataBinding support to observe (input-)model structure changes
> to refresh the viewer
> >
> > If we could come together that a structural change to the 2 dimension
> can only happen when a new input is set this is already supported by the
> current databinding lib (see ObservableListContentProvider).
> >
> >>
> >> d) a cell oriented DataBinding support for CellEditors
> >>
> >
> > Already reality but not part of the databinding framework but the
> changes in the JFace-API in 3.3 added the needed hooks ;-)
> >
> >
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.e xamples.databinding/src/org/eclipse/jface/examples/databindi ng/snippets/Snippet013TableViewerEditing.java?view=markup
>
> >
> > I'll comment more on these and other points after having thought more
> about it.
> >
> > Tom
> >
> >
>
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05226 seconds
] 
Search
Help
Register
Login
Home
