Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[DT] A couple of fixes discussed earlier with @apipkin and @lsmith #946
I am afraid the situation is quite worst than I thought and will need further study.
A column can have a
Since most columns have associated data, when the
However, when the columns definitions are cloned to the internal copy, two further properties are added: One is the
Also, in several places, the cell is located using the CSS className of the cell which is derived from the column
Besides this, there is always the conflict that the
I'm still to find out what the
So, there are too many ways to refer to a colun and they are not used consistently all across and, being poorly documented, later developers, as @apipkin or myself, can (and do) get caught. The
I haven't looked into all of it, I might still find out what is
So, just so you know, it is quite a mess!
Sorry, I meant to close a draft comment I was writing and closed the pull request instead. Sorry as well for the long comment above, but I wanted to put together all my thoughts.
This are some changes I suggest:
I'll start with those changes and see how they work out in the tests, but I'll love to hear your comments while I do so.
While doing the changes above I have found a bunch of inconsistencies in the use of all those identifiers which, no matter how to deal with the points above, will need to be addressed. Cells are located by CSS className selectors based on
They can be fixed without going through deprecating some of all those sources for identifiers:
As I went through all that code, I found myself wondering, whether the section views (head, body and foot) will ever be run independently. They all take a reference to a
I scaled back on the fixes to code (which I'm still eager to discuss) and submitted only the suggested documentation changes.
I added a fake
I believe this lack of a single place to document such an important set of configuration information to be the cause of a lot of errors in the code due to misunderstanding about what is what. All these properties were documented, somehow, but in the user guide or in API doc entries of the methods using those properties, not in a centralized and cross-linked fashion.
With this added information, I feel like much of those long descriptions at the top of several of the classes can go away as much of it is in the User Guide and the Columns, which were perhaps the main missing part, now do have their entries.
Those long Class descriptions are a little annoying as you have to scroll down several pages to get to whatever it is you are looking for. I'll be happy to check if anything in these descriptions is missing from other places such as the Users Guide or API docs and reduce them to the bare minimum.
@Satyam Yeah I'm totally feeling the notion of the headers being too large although I do not see those changes in this pull request. I have often felt DataTable was way too large for just one page in the user guides and forces the need to put extra documentation in the API docs.
I'll be checking this in today and testing it out and hopefully get it into dev-3.x.
@apipkin The headers are there indeed, I asked for comments on whether anybody else felt the headers could be stripped. Actually, many of the comments above are suggestions for comments. Very few of them did I translate into actual code since a few of them might risk breaking backward compatibility, though I can hardly imagine anyone using them.
One item that I would really like everyone's opinion on is whether to keep the separate section views as standalone, with conditionals asking whether there is a
I think there is a lot to be said for the idea of a view being independent of the host. However, there is a lot of code in the view that doesn't exist or work at all without one it seems. At the very least, it seems to add a lot of overhead and complexity. My opinion is that the views should be swappable, but the host should not be. I think if we remove this type of conditional contract in the views, the complexity of the views could go way down. My fear is that this will cause an issue with backwards compatibility.
@lsmith what is your thoughts on this? What was your plan with this design pattern originally?
I'm going to ramble a bit here, so bear with me.
I was just learning how to use Views when building it. I built it wrong. There should only be one view for the entire table, if any at all (versus having the rendering code directly in the widget). The view, if it exists, should be responsible for rendering the configuration state into the DOM and firing events in response to user interaction. The widget (base) should subscribe to those events and modify attribute state, which the view would propagate back to the DOM. The challenging part is justifying why there needs to two objects in the first place, since the table is essentially a view of a ModelList. Beyond the
I don't know what the consensus is on the YUI team wrt #2, or if there are guidelines for the breakdown between widgets and views/models when it comes to building new components. This was an open issue when I left.
Ignoring any (possibly imagined) motivation to avoid widget in favor of model/view constructions, DataTable does seem a good candidate for Widget, since it uses the attributes that differentiate between Widget and Base.
What follows is a question of features. Should widget features be added via plugin, or is the
I can see a world where a DT widget exists as well as a series of Node plugins to enable features for existing nodes, without the need for a complex table widget. I've often wondered how far I could get, starting from the node plugin angle instead. Mixing and matching features could quickly become a nightmare in this scenario, but maybe a compatibility matrix would be possible, with the DT widget allowing for full coexistence at the cost of complexity.
Now back to your question.
A standalone table View makes sense insofar as my above rant hasn't persuaded you that maybe there shouldn't be any Views in DT at all. I can't see a substantial value in having the thead and tbody Views standalone. The introduction of the table View was the first step in phasing them out. So I'm not terribly concerned about maintaining any perceived "architectural purity" when it comes to the sub-Views packaged with the core DT. Please feel free to improve the systems inside DT as you see fit.
@Satyam, sorry I haven't responded to your individual questions. There's a lot of code and architecture in DT to upload into my brain before giving a meaningful, and hopefully accurate response. I haven't done that because of other tasks that require my time and attention. And to be honest, at this point, you and @apipkin probably understand DT well enough that I'd be catching up with you to add my voice to the conversation, but little value.
@lsmith I think this is a very well thought post and I can say I agree with your position and as I feel Model + ModelList + View is the correct approach here as a base component. I think DT is a complex beast overall and there is a need for several positions around all of this. That being said, a view approach is clearly the best, especially when scrolling or resizing is added to it. I personally think there are some things that could be addressed a little better (clearer?) than the way it is currently set up.
For instance, right now there are three files that seems necessary for a single DT to be rendered: core, base, and table. I cannot for the life of me understand why this is in so many pieces and mixes in a View with a Widget which sounds like overkill to me.
There is also the idea of the templates living in separate files, which I addressed in the Paginator addition to DataTable. Paginator also took on the role of having a Model + View + Controller where the Controller was
new topic piece?
I think there is a limitation to the current structure of DT as it is a very flat architecture living under the full umbrella of YUI. There should be a directory for templates, models, views, and controllers (similar to https://gist.github.com/apipkin/5953144?). They should be perceived as individual files and should be able to be swapped out or added to as needed. The only problem with this thought is a third introduction to a new architecture of DT and may be frowned upon or leave people with a very bad taste in their mouth. I think there is a lot of good in the way DT is currently built, but as we pile more and more on it, there seems to be some weakness in it. It seems as though any update or addition renders the topic of "this broke that, so we have to update that to make this work, but if we do, this other thing wont work any more" and maybe a compatibility matrix is the best solution.
Now bear in mind that I am by no means proposing a solution to the issue at hand, nor am I saying we start from scratch. But there is room for improvement, and there is possibly a way to reach the speed that I would like to see and promote as much flexibility as it currently has or even add more to it.
@Satyam I love this PR. The added docs are fantastic and the minor code updates definitely help readability. A big
As to the code/architectural discussion above, let's move that to an issue rather than let it hold up this PR.