Closed qx-bug-importer closed 8 years ago
qx-bug-importer
commented
13 years ago Derrell Lipman (@derrell) wrote:
This does appear to be a bug, but it is really obscure. Changing the table model like that is a very unusual thing to do. Can you explain what you're trying to accomplish? Before we determine the priority of fixing this, I'd like to have a better idea of your use case. I expect that it can be as easily accomplished using more traditional methodologies.
Derrell
qx-bug-importer
commented
13 years ago Olivier ZORO-BI - Novlog (olivier.zoro-bi) wrote:
> This does appear to be a bug, but it is really obscure. Changing the table > model like that is a very unusual thing to do. Can you explain what you're > trying to accomplish? Before we determine the priority of fixing this, I'd like > to have a better idea of your use case. I expect that it can be as easily > accomplished using more traditional methodologies. > > Derrell
We use in fact a tree with different folders . Clicking on a folder shows on the right part a ui with tabviewPages containing widgets in which can be found tables. All the folders show quite the same UI. So, by clicking on the tree we use the same instances of widgets and so the same instances of tables. Only the model changes.
Were are very worried about the fact that changing the model may cause problems since it is very usual with Swing and the Model-View-Controller(MVC) : the model can change but the view is the same. Changing the view at each change of the model would remove the usefulness of MVC.
The bug was detected using Selenium Test which automatically click on tables cells and it failed with no real reason.
I hope I have been clear.
Olivier.
qx-bug-importer
commented
13 years ago Derrell Lipman (@derrell) wrote:
> We use in fact a tree with different folders . Clicking on a folder shows on > the right part a ui with tabviewPages containing widgets in which can be found > tables. > All the folders show quite the same UI. So, by clicking on the tree we use the > same instances of widgets and so the same instances of tables. Only the model > changes. > > Were are very worried about the fact that changing the model may cause problems > since it is very usual with Swing and the Model-View-Controller(MVC) : the > model can change but the view is the same. Changing the view at each change of > the model would remove the usefulness of MVC.
In the current implementation of Table, it is not possible to change the number of columns in a table once set. This is, I believe, a design defect, but is not being addressed in Table. Because of this, though, changing the model, as opposed to simply setting the data in the model, really doesn't make any sense. The "model" in MVC, as applied to a Table, is really the data in the model, and you can always change the data that is applied to the model by calling model.setData(newData). That should provide you the same capability you were looking for, just in a slightly different form.
Derrell
qx-bug-importer
commented
13 years ago Olivier ZORO-BI - Novlog (olivier.zoro-bi) wrote:
> > > We use in fact a tree with different folders . Clicking on a folder shows on > > the right part a ui with tabviewPages containing widgets in which can be found > > tables. > > All the folders show quite the same UI. So, by clicking on the tree we use the > > same instances of widgets and so the same instances of tables. Only the model > > changes. > > > > Were are very worried about the fact that changing the model may cause problems > > since it is very usual with Swing and the Model-View-Controller(MVC) : the > > model can change but the view is the same. Changing the view at each change of > > the model would remove the usefulness of MVC. > > In the current implementation of Table, it is not possible to change the number > of columns in a table once set. This is, I believe, a design defect, but is not > being addressed in Table. Because of this, though, changing the model, as > opposed to simply setting the data in the model, really doesn't make any sense. > The "model" in MVC, as applied to a Table, is really the data in the model, and > you can always change the data that is applied to the model by calling > model.setData(newData). That should provide you the same capability you were > looking for, just in a slightly different form. > > Derrell
I tried to only change the data using model.setData(newData), as it is used in my code [1]. But the same issue appears.
Olivier
qx-bug-importer
commented
13 years ago Derrell Lipman (@derrell) wrote:
> I tried to only change the data using model.setData(newData), as it is used in > my code [1]. > But the same issue appears. > > [1] http://tinyurl.com/39wmw9h
You should certainly, I think, be able to do what you're trying here. This is a real bug in a normal-use scenario.
Martin, this deserves attention. I don't have the time to work on it right now. I'll let you assign a priority and assignee.
Derrell
qx-bug-importer
commented
13 years ago Olivier ZORO-BI - Novlog (olivier.zoro-bi) wrote:
> > > I tried to only change the data using model.setData(newData), as it is used in > > my code [1]. > > But the same issue appears. > > > > [1] http://tinyurl.com/39wmw9h > > You should certainly, I think, be able to do what you're trying here. This is a > real bug in a normal-use scenario. > > Martin, this deserves attention. I don't have the time to work on it right > now. I'll let you assign a priority and assignee. > > Derrell
Hi, Thanks of the attention given to this bug which is really blocking for our tests. Is it possible to have the priority assigned to it and a potential delay of it's resolution?
Olivier
qx-bug-importer
commented
13 years ago Andreas Ecker (@ecker) wrote:
Olivier,
Martin will continue with the regular bug triage on Monday. He was sick the entire week and not at work, and given that we are close to the next release we have to see if and how we could address the issue. If it is that important for you and you'd be able to help resolving the issue, that would be a plus.
qx-bug-importer
commented
13 years ago Derrell Lipman (@derrell) wrote:
The bug seems to have to do with addRows(), a method that I've never used before. If you change your cellClick listener like this, it works:
table.addListener("cellClick", function() { tableModel.setData([["new role"]]); table.resetSelection(); // optional });
So as a work-around, instead of adding rows by calling addRows(), add them to your locally-maintained data array and call setData() with it.
Derrell
qx-bug-importer
commented
13 years ago Derrell Lipman (@derrell) wrote:
Changed the summary
qx-bug-importer
commented
13 years ago Martin Wittemann (@wittemann) wrote:
To me. As Derrell posted a workaround, we will not include a fix in the upcoming release.
qx-bug-importer
commented
13 years ago Olivier ZORO-BI - Novlog (olivier.zoro-bi) wrote:
> To me. > As Derrell posted a workaround, we will not include a fix in the upcoming > release.
Hi, I think the issue is not the addRows method but tableModel.setData([]) two times, which is done in my code.
I replaced the addRows method with setData [1] but there is the same problem.
qx-bug-importer
commented
13 years ago Derrell Lipman (@derrell) wrote:
> > > To me. > > As Derrell posted a workaround, we will not include a fix in the upcoming > > release. > > Hi, I think the issue is not the addRows method but tableModel.setData([]) two > times, which is done in my code. > > I replaced the addRows method with setData [1] but there is the same problem. > > > [1] http://tinyurl.com/38tz2ww
Ok. The problem is that for some reason an empty array of rows is causing a problem. I also see that using removeRows() is causing it to fail. Something is definitely wrong, but you can get around all issues except removing all rows from the table by simply setting the new data and not trying to clear the old data first.
It is a big problem that there currently appears to be no way to remove all rows from the table. The closest you can come is passing an array containing an empty array, yielding one row with no data: tableModel.setData([[]]);
Martin, if at all possible, this really ought to be addressed for the upcoming release. It's a pretty big deal that you can't delete all rows from the table.
Derrell
qx-bug-importer
commented
13 years ago Derrell Lipman (@derrell) wrote:
Corrected summary again
qx-bug-importer
commented
13 years ago Olivier ZORO-BI - Novlog (olivier.zoro-bi) wrote:
> Corrected summary again
I don't know if I got everything you said but do you mean there is no issue setting new data instead of clear all rows?
In the URL I posted I don't try to remove rows, it's commented. So simply setting new data causes the same issue.
Olivier
qx-bug-importer
commented
13 years ago Derrell Lipman (@derrell) wrote:
> I don't know if I got everything you said but do you mean there is no issue > setting new data instead of clear all rows? > > In the URL I posted I don't try to remove rows, it's commented. So simply > setting new data causes the same issue.
The problem is setting the data to "no rows" using tableModel.setData([]); That fails. Just don't do it. Use only the next line you have in your demo, which actually sets the new data. Granted it's not ideal, because there's no way to remove all rows, but as long as you don't have a requirement to remove all rows, you can call setData, providing a valid array of arrays of cell data, and it works correctly.
Derrell
qx-bug-importer
commented
13 years ago Olivier ZORO-BI - Novlog (olivier.zoro-bi) wrote:
> > I don't know if I got everything you said but do you mean there is no issue > > setting new data instead of clear all rows? > > > > In the URL I posted I don't try to remove rows, it's commented. So simply > > setting new data causes the same issue. > > The problem is setting the data to "no rows" using tableModel.setData([]); > That fails. Just don't do it. Use only the next line you have in your demo, > which actually sets the new data. Granted it's not ideal, because there's no > way to remove all rows, but as long as you don't have a requirement to remove > all rows, you can call setData, providing a valid array of arrays of cell data, > and it works correctly. > > Derrell
Ok I get you, but the fact is that in my application only the user clicks a button to add a new row. If I don't set data to "no rows" using tableModel.setData([]), the new view will be the same as the next and if no data is added (no row on the table) we will keep the previous rows.
How could I assure the facts that we don't keep the same view changing the model and that putting no data is possible?
Olivier
qx-bug-importer
commented
13 years ago Derrell Lipman (@derrell) wrote:
> Ok I get you, but the fact is that in my application only the user clicks a > button to add a new row. If I don't set data to "no rows" using > tableModel.setData([]), the new view will be the same as the next and if no > data is added (no row on the table) we will keep the previous rows. > > How could I assure the facts that we don't keep the same view changing the > model and that putting no data is possible?
It seems that there is no means available, at the moment, to change the table from having data, to having no data (short of removing the table and adding a new one -- a gross hack). That bug needs fixing.
You should be able to provide the entire data array to setData() at any time (as long as it contains at least one row), and have it update the table. When your user clicks the "Add Row" button, you should add the data to your locally-maintained rowData array, and pass that rowData array to setData().
Derrell
qx-bug-importer
commented
13 years ago Jean-Baptiste Briaud -- Novlog (j-b.briaud) wrote:
For performance purpose, we keep only one table widget instance for several set of data (different rows and sometimes different columns). Only one set of data can be visible at one time.
Some solution identified :
Any other ideas welcome !
Olivier, can you ensure all had been try ?
qx-bug-importer
commented
13 years ago Jean-Baptiste Briaud -- Novlog (j-b.briaud) wrote:
> You should be able to provide the entire data array to setData() at any time > (as long as it contains at least one row), and have it update the table. When > your user clicks the "Add Row" button, you should add the data to your > locally-maintained rowData array, and pass that rowData array to setData().
That's exactly what we are doing except that data set doesn't always contains one row. That's why we have to clear the table between data set
qx-bug-importer
commented
13 years ago Olivier ZORO-BI - Novlog (olivier.zoro-bi) wrote:
> For performance purpose, we keep only one table widget instance for several set > of data (different rows and sometimes different columns). > Only one set of data can be visible at one time. > > Some solution identified : > 1. Instantiate a new table each time. The whole thing is design for not doing > that, so we can't change without recoding everything. > > 2. Removing all rows > > 3. Adding empty rows > > 4. Instantiating a new model and set it to the table > > Any other ideas welcome ! > > Olivier, can you ensure all had been try ?
Instanciating a new model and setting it to the table only after adding rows seems to work. http://tinyurl.com/2demgq5
qx-bug-importer
commented
13 years ago Olivier ZORO-BI - Novlog (olivier.zoro-bi) wrote:
> For performance purpose, we keep only one table widget instance for several set > of data (different rows and sometimes different columns). > Only one set of data can be visible at one time. > > Some solution identified : > 1. Instantiate a new table each time. The whole thing is design for not doing > that, so we can't change without recoding everything. > > 2. Removing all rows > > 3. Adding empty rows > > 4. Instantiating a new model and set it to the table > > Any other ideas welcome ! > > Olivier, can you ensure all had been try ?
I am looking for a workaround without instanciating a new table.
Instanciating a new model and set it to the table doesn't work either.
the table can't be used again for another model.
Have you had some more ideas?
Using a new table is a too big refactoring for our code.
Olivier
qx-bug-importer
commented
13 years ago Olivier ZORO-BI - Novlog (olivier.zoro-bi) wrote:
> > > For performance purpose, we keep only one table widget instance for several set
> > of data (different rows and sometimes different columns).
> > Only one set of data can be visible at one time.
> >
> > Some solution identified :
> > 1. Instantiate a new table each time. The whole thing is design for not doing
> > that, so we can't change without recoding everything.
> >
> > 2. Removing all rows
> >
> > 3. Adding empty rows
> >
> > 4. Instantiating a new model and set it to the table
> >
> > Any other ideas welcome !
> >
> > Olivier, can you ensure all had been try ?
>
> I am looking for a workaround without instanciating a new table.
> Instanciating a new model and set it to the table doesn't work either.
> the table can't be used again for another model.
> Have you had some more ideas?
> Using a new table is a too big refactoring for our code.
>
> Olivier
I forgot to post an URL : http://tinyurl.com/32yzf6l.
qx-bug-importer
commented
13 years ago Olivier ZORO-BI - Novlog (olivier.zoro-bi) wrote:
> > > > > > For performance purpose, we keep only one table widget instance for several set
> > > of data (different rows and sometimes different columns).
> > > Only one set of data can be visible at one time.
> > >
> > > Some solution identified :
> > > 1. Instantiate a new table each time. The whole thing is design for not doing
> > > that, so we can't change without recoding everything.
> > >
> > > 2. Removing all rows
> > >
> > > 3. Adding empty rows
> > >
> > > 4. Instantiating a new model and set it to the table
> > >
> > > Any other ideas welcome !
> > >
> > > Olivier, can you ensure all had been try ?
> >
> > I am looking for a workaround without instanciating a new table.
> > Instanciating a new model and set it to the table doesn't work either.
> > the table can't be used again for another model.
> > Have you had some more ideas?
> > Using a new table is a too big refactoring for our code.
> >
> > Olivier
>
> I forgot to post an URL : http://tinyurl.com/32yzf6l.
I tried to avoid to use addRows as said initially. It works with setData[1]. The bug is definitively to remove a row. In facts it's impossible to change the model (remove rows and add others) of the table without editing problems.
In [1] I re-use the previous rows data (data = data.concat([["new man"]]); tableModel.setData(data);) Here again, I'm obliged to create a new instance of table instead of simply keep alive the previous table with data.push(["new man"]); push method doesn't work here. [2]
qooxdoo tables have a problem of MVC managemant.
[1] http://tinyurl.com/2c7mr3p [2] http://tinyurl.com/27er4vd
qx-bug-importer
commented
13 years ago Olivier ZORO-BI - Novlog (olivier.zoro-bi) wrote:
> The fact is that when you give another model to the same table instance, > the last corresponding edited cell on the previous model can't be edited > on the new model. > > On the given link [1], to reproduce the bug, you have to right click on the > first cell (clicking on the second will not reproduce the bug), a new model > will be > given to the same table instance. You will have then a new cell with > "new age" data. > It's impossible to doubleCLick on this cell. A new right Click on this > cell will add a new row on which you can now doucleClick. After this it > is possible to doubleClick on the first one cell. > Tell me if it is really a bug. I think it is why using directly > qx.ui.table.Table class, I can edit only one time my table. The second > time, when a new model is given, I can't edit cell(0,0). I'm obliged to > edit cell(0,1). > > Ps: don't care about listeners types, they are only pretexts to reproduce > the bug. > > [1] http://tinyurl.com/3xnqan7
> > > > > > > > > > For performance purpose, we keep only one table widget instance for several set
> > > > of data (different rows and sometimes different columns).
> > > > Only one set of data can be visible at one time.
> > > >
> > > > Some solution identified :
> > > > 1. Instantiate a new table each time. The whole thing is design for not doing
> > > > that, so we can't change without recoding everything.
> > > >
> > > > 2. Removing all rows
> > > >
> > > > 3. Adding empty rows
> > > >
> > > > 4. Instantiating a new model and set it to the table
> > > >
> > > > Any other ideas welcome !
> > > >
> > > > Olivier, can you ensure all had been try ?
> > >
> > > I am looking for a workaround without instanciating a new table.
> > > Instanciating a new model and set it to the table doesn't work either.
> > > the table can't be used again for another model.
> > > Have you had some more ideas?
> > > Using a new table is a too big refactoring for our code.
> > >
> > > Olivier
> >
> > I forgot to post an URL : http://tinyurl.com/32yzf6l.
>
> I tried to avoid to use addRows as said initially. It works with setData[1].
> The bug is definitively to remove a row. In facts it's impossible to change the
> model (remove rows and add others) of the table without editing problems.
>
> In [1] I re-use the previous rows data (data = data.concat([["new man"]]);
> tableModel.setData(data);) Here again, I'm forced to create a new instance of
> array instead of simply keep alive the previous array with data.push(["new
> man"]); push method doesn't work here. [2]
>
> qooxdoo tables have a problem of MVC managemant.
>
> [1] http://tinyurl.com/2c7mr3p
> [2] http://tinyurl.com/27er4vd
qx-bug-importer
commented
13 years ago Olivier ZORO-BI - Novlog (olivier.zoro-bi) wrote:
> > > The fact is that when you give another model to the same table instance,
> > the last corresponding edited cell on the previous model can't be edited
> > on the new model.
> >
> > On the given link [1], to reproduce the bug, you have to right click on the
> > first cell (clicking on the second will not reproduce the bug), a new model
> > will be
> > given to the same table instance. You will have then a new cell with
> > "new age" data.
> > It's impossible to doubleCLick on this cell. A new right Click on this
> > cell will add a new row on which you can now doucleClick. After this it
> > is possible to doubleClick on the first one cell.
> > Tell me if it is really a bug. I think it is why using directly
> > qx.ui.table.Table class, I can edit only one time my table. The second
> > time, when a new model is given, I can't edit cell(0,0). I'm obliged to
> > edit cell(0,1).
> >
> > Ps: don't care about listeners types, they are only pretexts to reproduce
> > the bug.
> >
> > [1] http://tinyurl.com/3xnqan7
>
> > > > > > > > > > > > > > > For performance purpose, we keep only one table widget instance for several set
> > > > > of data (different rows and sometimes different columns).
> > > > > Only one set of data can be visible at one time.
> > > > >
> > > > > Some solution identified :
> > > > > 1. Instantiate a new table each time. The whole thing is design for not doing
> > > > > that, so we can't change without recoding everything.
> > > > >
> > > > > 2. Removing all rows
> > > > >
> > > > > 3. Adding empty rows
> > > > >
> > > > > 4. Instantiating a new model and set it to the table
> > > > >
> > > > > Any other ideas welcome !
> > > > >
> > > > > Olivier, can you ensure all had been try ?
> > > >
> > > > I am looking for a workaround without instanciating a new table.
> > > > Instanciating a new model and set it to the table doesn't work either.
> > > > the table can't be used again for another model.
> > > > Have you had some more ideas?
> > > > Using a new table is a too big refactoring for our code.
> > > >
> > > > Olivier
> > >
> > > I forgot to post an URL : http://tinyurl.com/32yzf6l.
> >
> > I tried to avoid to use addRows as said initially. It works with setData[1].
> > The bug is definitively to remove a row. In facts it's impossible to change the
> > model (remove rows and add others) of the table without editing problems.
> >
> > In [1] I re-use the previous rows data (data = data.concat([["new man"]]);
> > tableModel.setData(data);) Here again, I'm forced to create a new instance of
> > array instead of simply keep alive the previous array with data.push(["new
> > man"]); push method doesn't work here. [2]
> >
> > qooxdoo tables have a problem of MVC managemant.
> >
> > [1] http://tinyurl.com/2c7mr3p
> > [2] http://tinyurl.com/27er4vd
I come to a summary,
We can't do anymore for that bug which is very blocking.
We are waiting for your correction or another workaround.
qx-bug-importer
commented
13 years ago Jean-Baptiste Briaud -- Novlog (j-b.briaud) wrote:
Martin : Hi Martin, can we have a status update on that bug ? We did try hard but there is no workaround, any chance to include that bug in the next release ?
Thanks.
qx-bug-importer
commented
13 years ago Martin Wittemann (@wittemann) wrote:
Hello Jean-Baptiste, I haven't looked at this issue yet and I don't plan to include it into the upcoming release. I have still 20 bugs todo in two weeks so no chance to get that done, sorry. Regards, Martin
qx-bug-importer
commented
13 years ago Jean-Baptiste Briaud -- Novlog (j-b.briaud) wrote:
Another scenario I just encountred where changing table's row entierely is important : A GUI represent a person associated with some company. In order to change company associated to this person, a modal dialog box show the availlable companies. After having changed the associated company, one come back with the first table that have differents rows (same columns).
qx-bug-importer
commented
10 years ago Martin Wittemann (@wittemann) wrote:
Move open issues to RESOLVED – LATER, whose last comment is older than a year.
Olivier ZORO-BI - Novlog (olivier.zoro-bi) wrote:
The fact is that when you give another model to the same table instance, the last corresponding edited cell on the previous model can't be edited on the new model.
On the given link [1], to reproduce the bug, you have to right click on the first cell (clicking on the second will not reproduce the bug), a new model will be given to the same table instance. You will have then a new cell with "new age" data. It's impossible to doubleCLick on this cell. A new right Click on this cell will add a new row on which you can now doucleClick. After this it is possible to doubleClick on the first one cell. Tell me if it is really a bug. I think it is why using directly qx.ui.table.Table class, I can edit only one time my table. The second time, when a new model is given, I can't edit cell(0,0). I'm obliged to edit cell(0,1).
Ps: don't care about listeners types, they are only pretexts to reproduce the bug.
[1] http://tinyurl.com/3xnqan7
assigned to Martin Wittemann (@wittemann)