Purely 'data' tables as opposed to 'presentation' tables - is this possible?
Purely 'data' tables as opposed to 'presentation' tables - is this possible?
Allan,
What you have created is really AMAZING! But ...,
In many situations you have groups of fields which are not well presented as a table, rather each record could have its own 2-d layout. For instance, take profiles as an example, where you have a photo and fields with large chunks of text. With that, a row-based presentation does not work, and you need to lay headings and fields in two dimensions.
For these, I have been using a modification of show/hide example (http://www.datatables.net/examples/server_side/row_details.html). I have been getting quite imaginative with this method and have created profile-like layouts inside the hidden area.
Now I want to take this one step further. I want to let go of the 'table' in the sense of presentation and keep DT purely a data manipulator (something it is excellent at).
To do this I though maybe we could:
1. Build the layout at each row's rendering,
2. populate it with data, using the generated content instead of the show/hide icon, and
3. make all columns hidden, and finally
4. move all filtering and pagination controls to an arbitrary area of the page (e.g. bottom-left).
- Is this stretching DataTables too far?
- Are there better ways to do this?
- Would you consider extending/forking DT, to easily and efficiently offer liquid-presentation functionality?
- What are your feelings towards others (maybe me) forking DataTables?
Since this is a forum, I am addressing all who are interested, and invite them to offer insight and advice.
Thanks,
Majid
What you have created is really AMAZING! But ...,
In many situations you have groups of fields which are not well presented as a table, rather each record could have its own 2-d layout. For instance, take profiles as an example, where you have a photo and fields with large chunks of text. With that, a row-based presentation does not work, and you need to lay headings and fields in two dimensions.
For these, I have been using a modification of show/hide example (http://www.datatables.net/examples/server_side/row_details.html). I have been getting quite imaginative with this method and have created profile-like layouts inside the hidden area.
Now I want to take this one step further. I want to let go of the 'table' in the sense of presentation and keep DT purely a data manipulator (something it is excellent at).
To do this I though maybe we could:
1. Build the layout at each row's rendering,
2. populate it with data, using the generated content instead of the show/hide icon, and
3. make all columns hidden, and finally
4. move all filtering and pagination controls to an arbitrary area of the page (e.g. bottom-left).
- Is this stretching DataTables too far?
- Are there better ways to do this?
- Would you consider extending/forking DT, to easily and efficiently offer liquid-presentation functionality?
- What are your feelings towards others (maybe me) forking DataTables?
Since this is a forum, I am addressing all who are interested, and invite them to offer insight and advice.
Thanks,
Majid
This discussion has been closed.
Replies
For building 2-d layout for each row:
We can use 'fnRowCallback' to trigger the function that builds the 2-d layout representation of each row's data. Inside the function we have access to row's data with aData[] array.
For getting to sort even though we've made all columns hidden:
'fnSortListener' could be used to easily bestow sort operations to links or buttons in the 'control pad' sitting at bottom-left corner of screen.
For putting search box, length select, and pagination controls on the 'control pad':
... well, don't know exactly what could be done. Probably we could use adding inline CSS with absolute/fixed positioning via javascript. This could be triggered using 'fnInitComplete'. There also is the possibility of using 'sDom' option, but, to me at least, the 'pico-language' is cryptic and the example provided (http://datatables.net/examples/basic_init/dom.html) is not clear.
Sounds very interesting. It's certainly going to stretch DataTables since it will be used for something that it wasn't designed for, but at the same time it does sound possible and the code is there to be manipulated as you see fit.
> - What are your feelings towards others (maybe me) forking DataTables?
Please do! https://github.com/DataTables/DataTables/ - I'd be very interested to see what yourself and anyone else come up with.
> - Would you consider extending/forking DT, to easily and efficiently offer liquid-presentation functionality?
Liquid layout is a very admirable goal for DataTables. The reason for using fixed units at the moment is basically that it makes life much easier and is 'good enough' 90% or so of the time. Switching DataTables to be liquid layout probably wouldn't be too difficult for a regular HTML table - the real difficulty would come when considering the scrolling options in DataTables. But then you note that all columns will be hidden in your table - so I don't quite get how the drawing on page would be done?
Allan
We are hiding all the columns containing the dataset, but we are adding one ourselves which is not hidden. This is like the column you add to put the show/hide icon in show/hide example (http://www.datatables.net/examples/server_side/row_details.html) with 2 differences: (1) it is assigned 100% of the table width instead of 5% - because there are no more column to show, and (2) instead of the icon, it contains a container div into which we put the 2-d layout of that row's data with headings and markup of our own. So each 'row' as seen by DT will be 100% in width, and much bigger in height (like the [code]more info[/code] in your example).
In my second post to this topic I explained what callbacks and API methods could be used, so I think this could be achieved, but I think this is wasteful, because (1) DT spends time to create the row (2) we ask it to do additional work just to hide what it has built except the first custom added column (3) we query it to give us the data belonging to the row (4) we use that data to parse our 2-d presentation and inject it into the only visible column.
As you could see steps 1, and 2 are wasted here.
Majid
Okay I understand - thanks for the explanation. So really what you are looking for is a data processor, rather than a table display. I think DataTables might introduce more overhead than is needed - or in other words, this probably isn't an optimal way to do what you are looking for. Possibly yes, but it might be more appropriate to take some ideas from DataTables and implement something more efficient (something like using the server-side processing ideas suggests itself).
Allan
Allan