View Full Version : Preserving original table attributes when using Ext.grid.Grid Widget

28 Apr 2007, 6:23 AM
I have a problem using the Grid widget.
The problem is that after the grid is applied over the table using a template, the existing attributes (like id, onclick handler a.s.o) disappear.
How can I force the Ext.grid.Grid object to preserve (at least some explicitly specified) attributes when transforming the original table?

Any help would be appreciated

Thanks a lot.

28 Apr 2007, 6:42 AM
"grid is applied over the table using a template"

That doesn't ring any bells. Do you mean you are using the Ext.grid.TableGrid from the example directory to convert a table to a Grid?

Onclick handlers are deprecated anyway.

What programming problem are you trying to solve?

You can subscribe to the Grid's events:


And perform processing based on the cell's coordinates, or data...

28 Apr 2007, 1:04 PM
Sorry for mistake, I am using the table templates with Ext.grid.TableGrid instead of Ext.grid.Grid to convert a table to a Grid.

Subscription to the Grid's events is not a convenient solution to my problem. The main problem is that I am working with a lot of data, each table will have at least several hundreds of rows (with about 10 columns on each row)... subscribing to each event, means an additional overhead which will slow down a lot the application, resulting in unacceptable performance + it's hard to perform a processing based on the cell's coordinates (instead of reuse the original table events).

The idea is that having a table - I need to convert it to a grid, but in the same time to preserve the original table styling and behavior (preserve each [table, tr, td] tags attributes and events).
For instance:

<table id="mytable">
<tr class="r1">
<td class="c1">1</td>
<td id="ID1" onclick="serviceCall(URL1)" class="c2" style="font-weight:bold;">John</td>
<tr class="r1" onclick="serviceCall(URL2)">
<td class="c1">2</td>
<td id="ID2" onclick="serviceCall(URL3)" class="c2" style="font-weight:bold;">Mike</td>

By converting the above table to a Grid, I would expect that:
1. The resulted table would call exactly the same js function when user clicks its rows or cells.
2. Besides the generated classes and styles, the original styling would be present also on the resulted markup.
3. Any attribute (ex: id) applied on the original markup, would be present on the resulted markup

By converting from a table template to a grid, currently means that only data is copied from original table to the resulted table... but I found that this is not enough for my use case. Maybe you can see my problem as a request for enhancement, which could be implemented in next release of the YUI-ext. What do you think about it?

Thank you!


28 Apr 2007, 4:15 PM
You don't want to change the appearance of your table, you don't want to use the Ext grid events in place of inline onclicks in your table, and you have possibly 100s of rows in your table. What do you think you're going to gain by trying to implement it in a grid? Your current implementation is poor and there is no point in building a kludge to try and make it work better. The TableGrid is a lightweight implementation to provide basic grid functionality around a simple table. It's not some magic solution to allow you to put a pretty face on a legacy table construct.

28 Apr 2007, 10:36 PM
Thank guys from Ext Support team for quick replies.

Tim, it was just a sample table example, not my actual table implementation. What exactly is poor in its implementation? You cannot say it is poor as long as it just has attached some behavior and some cell row or cell styling, and in the same time respect the standard table markup...
All you want to say is that the TableGrid works only on static tables, with data which cannot interact with user? Why trying to make it work better, means building a kludge?

The table has 100s of rows because it is populated with data from DB and is generated on the server side using some web framework (Wicket in my case, but can be any other Spring MVC, Stripes or Struts).
What I'm trying to gain, is to combine TableGrid widget functionality (sorting, scrolling, fixed column, etc) with the server-side generated table, which also have a behavior like clicking on a cell - performs an ajax call to a server or change the clicked cell appearance.

Finally, all I need is just to know if would be possible to implement such a feature, which copies along with template table data, also it's attributes and events....

I'm not looking to a magic solution, I'm just trying to make my product look like magic! :)

Thank you!

29 Apr 2007, 12:25 AM
And it really will be much better for you if you simply attach one event listener to the Grid's cellclick event, and perform necessary processing there.

The way you have it, in a table with 10 columns and 300 rows, you are using 3000 listeners!

29 Apr 2007, 6:12 AM
... and it means 3000 more lines of js code => more traffic, less responsive application... And what if there are 2000 or 3000 rows?

I mentioned in the previous post that attaching event listeners is not enough and also is not a convenient solution.
As I understand from your reply, for Ext support team it is unwanted or impossible to implement feater (copying along with template table data, also it's attributes and events), is it correct?

Thank you!

29 Apr 2007, 9:12 AM
Don't post sample code and then come back and say 'that's not what I really meant' when somebody questions your code. You posted an example that shows events on every row of your table and inline styles. Do you think that's a good implementation? If you have 3000 rows in your table, do you really believe that it performs well and it's a good solution for the end user?

You really need to spend some time understanding the grid component before you try to tell others how to improve it. If you spend time reading the threads in this forum, you will find numerous discussions on how best to implement grids - whether it's an Ext grid or your table solution. None of them will tell you that it's a good idea to present 3000 rows to the user, or that to implement events you would wire 3000 handlers.

29 Apr 2007, 10:34 AM
What I was trying to do by posting a code sample, is to show that every event handler, style, class, id attributes should be preserved... believe me, I know that it is not best practice to write inline style.... but this is not the point.

Anyway, you should take in consideration that the table is constructed dynamically, events are wired dynamically, classes, styles, ID's and other attributes are also generated dynamically... so don't you believe that just wiring listeners would not help to reach the expected result?

I do not understand why instead of answer to a simple question (see title), what you are trying to do is to point to something else, which is not a problem at all. I am trying to find a solution which could be useful for any other developer and which would be a great enhancement for the library. I would greatly appreciate any help!

30 Apr 2007, 12:29 AM
The class could easily be modified to add the CSS class name from each THEAD>TH element into the generated ColumnModel for each column. That would be a useful enhancement.

Possibly also to add columns whose THEAD>TH is display:none to the Store, but not the ColumnModel, so that there can be extra data there available for processing, but not displayed. Eg, the URL to be processed for that row.

You could add either of these features to the TableGrid class that you have for now, and submit a feature request. Bear in mind that it is not a core part of Ext, just a class in an example. You can take ownership of it.

But an onclick on every table cell is a broken design.

"... and it means 3000 more lines of js code => more traffic, less responsive application... And what if there are 2000 or 3000 rows?"

What does that mean? Who suggested adding 1000s of lines of code?

You need one click handler on the Grid. The Grid's click event handler is passed all the details, and has access to all the data. You can process the clicks all in one function depending on the data.