Re: [qooxdoo-devel] Where's the bug? 2 : Qooxdoo Table remains empty
On 21.03.2011 14:56, Derrell Lipman wrote: > You are correct that it is much easier to debug with the source version > than with the build version. For those rare times that you _must_ debug > with the build version, in the "let" section of your config.json file, set > OPTIMIZE : [ ] > to turn off all optimization, so at least the code is readable. That > won't add back in all of the debugging code, though. That's done through > a change of "settings" which I don't recall off hand how to do. > > In your case, though, the problem would almost certainly have been > detected by a decent debugger. Although I prefer Chrome for all normal > use, I use Firefox with the Firebug debugger for all qooxdoo debugging, > as I find it much easier to use than Chrome's debugger, and does a great > job of catching this sort of error. I would have stopped at the errant > line, and you could then have seen that the parameter to > qx.bom.String.escape was null, and looked at the stack trace to see > where it had been called from. Developing medium and large size > applications without a good debugger is, in my opinion, a huge waste of > time. Thanks for pointing this out. Note that I *did* use FireBug (Firefox 3.6.13 on Windows) and Google Chrome. But there is no stacktrace and no indication of any error in either Firebug nor Chrome Development Tools! Since we are moving away from the initial question (which is answered), I'll post another message "Getting debug messages in a built version" to continue this topic. Luc -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] Where's the bug? 2 : Qooxdoo Table remains empty
On Mon, Mar 21, 2011 at 06:39, Luc Saffre wrote: > Uff! Here is the answer! And a new (much easier) question. > > There was an exception thrown during my self-written cell renderer. I > didn't even include the code of this class because I didn't expect that > kind of surprise (so I admit that you had no chance to find it). > ... > The problem is that I call `qx.bom.String.escape` possibly with a null > value. Changing the line > > return qx.bom.String.escape(s); /** here it is **/ > > into > > if (s) return qx.bom.String.escape(s); > > did solve my problem. > > And my new question is: how is it possible that I didn't get any > notification of that exception? I guess it is because I use the built > and not the source version? Is that correct? > > My lesson from this story: don't use the built version for debugging. You are correct that it is much easier to debug with the source version than with the build version. For those rare times that you _must_ debug with the build version, in the "let" section of your config.json file, set OPTIMIZE : [ ] to turn off all optimization, so at least the code is readable. That won't add back in all of the debugging code, though. That's done through a change of "settings" which I don't recall off hand how to do. In your case, though, the problem would almost certainly have been detected by a decent debugger. Although I prefer Chrome for all normal use, I use Firefox with the Firebug debugger for all qooxdoo debugging, as I find it much easier to use than Chrome's debugger, and does a great job of catching this sort of error. I would have stopped at the errant line, and you could then have seen that the parameter to qx.bom.String.escape was null, and looked at the stack trace to see where it had been called from. Developing medium and large size applications without a good debugger is, in my opinion, a huge waste of time. Cheers, Derrell -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] Where's the bug? 2 : Qooxdoo Table remains empty
Uff! Here is the answer! And a new (much easier) question.
There was an exception thrown during my self-written cell renderer. I
didn't even include the code of this class because I didn't expect that
kind of surprise (so I admit that you had no chance to find it). Here is
the buggy code::
qx.Class.define("lino.ForeignKeyCellRenderer",
{
extend : qx.ui.table.cellrenderer.String,
construct : function(colIndex)
{
this.base(arguments);
this.__colIndex = colIndex;
},
members :
{
__colIndex : null,
_getContentHtml : function(cellInfo) {
if (cellInfo.rowData) {
var s = cellInfo.rowData[this.__colIndex];
return qx.bom.String.escape(s); /** here it is **/
}
return "";
}
}
});
The problem is that I call `qx.bom.String.escape` possibly with a null
value. Changing the line
return qx.bom.String.escape(s); /** here it is **/
into
if (s) return qx.bom.String.escape(s);
did solve my problem.
And my new question is: how is it possible that I didn't get any
notification of that exception? I guess it is because I use the built
and not the source version? Is that correct?
My lesson from this story: don't use the built version for debugging.
Luc
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] Where's the bug? 2 : Qooxdoo Table remains empty
On 18.03.2011 16:33, Derrell Lipman wrote:
>
> Nope, you misunderstood me. I wanted you to make ONLY the one-line
> change of removing the column id values from the call to
> tm.setColumns(), so that it looks like this:
>
> tm.setColumns( [ "ID", "name", "name (et)", "Category", "vatExempt",
> "price", "description", "description (et)" ]);
>
> Note that only one parameter is passed. Then go back to your
> original data being returned from the server. With that
> configuration, you're using the Remote data model in the way that
> it's typically used, and it should work for you.
>
> Have you looked at the Remote Data Model example in the demobrowser
> or in the RpcExample contrib? These are both working examples of
> using that model. (You'll need to download the demobrowser source to
> see what it's doing, since it uses some classes that don't show up in
> the Source panel.)
Thanks for the pointer to RpcExample. After looking into RpcExample I
suppose you mean I should call setColumnIds in the constructor of my
RemoteTableModel to specify the column IDs ('name_et' etc.), and then I
can use setColumns with only the first parameter ('name (et)', etc.). I
tried this (once using strings and a map for each record, once using
indexes and a list for each record). Result: no change. I also saw that
you specify the column ids ([ "year", "leap" ]) twice. I tried that,
too. Still no change.
I'm getting more and more convinced that the bug is not in the columns
definition. Another reason for saying this is that if you look at the
console output on http://lino.saffre-rumma.net/tickets/33.html you can
see that the data "arrives correctly" at the client. It just doesn't
find it's way to the screen...
I continue to hope for more ideas from people on this list, especially
because I probably won't be able to work much on this until Wednesday.
Luc
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] Where's the bug? 2 : Qooxdoo Table remains empty
On Fri, Mar 18, 2011 at 10:23, Luc Saffre wrote:
> On 18.03.2011 14:42, Derrell Lipman wrote:
> > Some people love the column ids. Personally, I've never found a great
> > use for them. When they're used, however, they re typically strings, not
> > numbers, and without looking at the code, I'm not sure what problems
> > using numbers would cause. Also, I think when you use them, the format
> > of your data returned by the server must be in the map format, not the
> > simple array format as you're using.
> >
> > To test my hypothesis, please remove the second parameter to
> > tm.setColumns() and see if your results are more favorable.
>
> Derrell, thanks for not leaving me alone.
>
> Yes it's true that most examples and the docs seem to say that the
> individual rows should be maps and not arrays. So I tried your suggestion::
>
> tm.setColumns(
>[ "ID", "name", "name (et)", "Category", "vatExempt", "price",
> "description", "description (et)" ],
> [ "id", "name", "name_et", "cat", "vatExempt", "price",
> "description", "description_et" ]
> ); // columnNameArr, columnIdArr
>
> and changed the server to respond like this::
>
> { "count": 10, "rows": [
> { "name_et": "Laud puidust", "catHidden": 1, "name": "Wooden table",
> },
> { "name_et": "Tool puidust", "catHidden": 1, "name": "Wooden chair",
> ...}, ...
> ],
> "title": "Products"
> }
>
> But sorry, you don't get the prize: unfortunately the problem remains.
> Or I'd rather say *fortunately* because AFAICS from the source,
> qx.ui.table.model.Remote perfectly supports simple arrays instead of
> maps. I prefer to use simple lists (not maps) because it saves bandwidth
> and client memory, and it would be redundant to repeat the column names
> for each row of a table.
>
Nope, you misunderstood me. I wanted you to make ONLY the one-line change of
removing the column id values from the call to tm.setColumns(), so that it
looks like this:
tm.setColumns(
[ "ID", "name", "name (et)", "Category", "vatExempt",
"price", "description", "description (et)" ]);
Note that only one parameter is passed. Then go back to your original data
being returned from the server. With that configuration, you're using the
Remote data model in the way that it's typically used, and it should work
for you.
Have you looked at the Remote Data Model example in the demobrowser or in
the RpcExample contrib? These are both working examples of using that model.
(You'll need to download the demobrowser source to see what it's doing,
since it uses some classes that don't show up in the Source panel.)
Cheers,
Derrell
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] Where's the bug? 2 : Qooxdoo Table remains empty
On 18.03.2011 14:42, Derrell Lipman wrote:
> Some people love the column ids. Personally, I've never found a great
> use for them. When they're used, however, they re typically strings, not
> numbers, and without looking at the code, I'm not sure what problems
> using numbers would cause. Also, I think when you use them, the format
> of your data returned by the server must be in the map format, not the
> simple array format as you're using.
>
> To test my hypothesis, please remove the second parameter to
> tm.setColumns() and see if your results are more favorable.
Derrell, thanks for not leaving me alone.
Yes it's true that most examples and the docs seem to say that the
individual rows should be maps and not arrays. So I tried your suggestion::
tm.setColumns(
[ "ID", "name", "name (et)", "Category", "vatExempt", "price",
"description", "description (et)" ],
[ "id", "name", "name_et", "cat", "vatExempt", "price",
"description", "description_et" ]
); // columnNameArr, columnIdArr
and changed the server to respond like this::
{ "count": 10, "rows": [
{ "name_et": "Laud puidust", "catHidden": 1, "name": "Wooden table",
},
{ "name_et": "Tool puidust", "catHidden": 1, "name": "Wooden chair",
...}, ...
],
"title": "Products"
}
But sorry, you don't get the prize: unfortunately the problem remains.
Or I'd rather say *fortunately* because AFAICS from the source,
qx.ui.table.model.Remote perfectly supports simple arrays instead of
maps. I prefer to use simple lists (not maps) because it saves bandwidth
and client memory, and it would be redundant to repeat the column names
for each row of a table.
I continue to hope for ideas form this list!
Luc
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] Where's the bug? 2 : Qooxdoo Table remains empty
On Fri, Mar 18, 2011 at 04:12, Luc Saffre wrote:
> Here is another riddle which took me already a whole workday and for
> which I hope that some experienced Qx user will find the solution at a
> glance. Thanks in advance for any hint. Even vague suggestions are
> welcome, because currently I'm stuck like a duck in a thunderstorm...
>
> (The following text, including the 2 screenshots, is also at
> http://lino.saffre-rumma.net/tickets/33.html)
>
> Luc
>
...
> qx.Class.define("lino.products_Products_grid",
> {
>extend : lino.TableWindow,
>members : {
> content_type : 19,
> before_row_edit : function(record){},
> createTable : function() {
>var tm = new lino.RemoteTableModel(this,'/api/products/Products');
>tm.setColumns(
> [ "ID", "name", "name (et)", "Category", "vatExempt", "price",
> "description", "description (et)" ],
> [ 0, 1, 2, 3, 5, 6, 7, 8 ]
>); // columnNameArr, columnIdArr
>
Some people love the column ids. Personally, I've never found a great use
for them. When they're used, however, they re typically strings, not
numbers, and without looking at the code, I'm not sure what problems using
numbers would cause. Also, I think when you use them, the format of your
data returned by the server must be in the map format, not the simple array
format as you're using.
To test my hypothesis, please remove the second parameter to tm.setColumns()
and see if your results are more favorable.
Derrell
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
