Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.hi there,
I need to integrate sheetnode into a site so that the sheets are displayed as tables, but without using javascript so that the content can be indexed by search engines.
my idea would be to create a CCK 'Sheetnode display' module which renders the table in question into HTML and embeds it into the node. of course the node would need to be a 'sheetnode'.
I've already looked at the 'CCK Sheetfield' module but this won't solve my problem and the site already has content created using the 'sheetnode' content type and migration is not really something I want to get stuck into at this stage. Plus I prefer the options available with using an actual 'sheetnode'.
my question is whether you feel this is the appropriate approach in the context of the project and whether you have any pointers on how best to approach it. I would hope to create something which I could contribute back to the project.
best regards,
mark
Comments
Comment #1
infojunkieThe current Sheetnode dev provides a setting to select the rendering mode for node views (admin/settings/sheetnode). I suggest to extend this setting with a 4th option for pure HTML rendering (or to change the 3rd option to use PHP-based HTML rendering instead of the current JavaScript approach). To do this, we need to convert the JS function
SocialCalc.SpreadsheetViewerCreateSheetHTML()(in file socialcalc/socialcalcviewer.js) to PHP.To support the same for CCK sheetfields, I suggest creating field formatters for the above options in function
sheetnode_field_formatter_info()(in file sheetnode.module).Comment #2
markchitty commentedThis sounds like a good approach and I've gone some way to implementing it. However, I am still considering a CCK based approach as I would like to make use of the CCK field permissions to control access to the HTML rendered version of the tables, there is also a need to display tables as charts at some point in the future and I wonder whether this modular approach might make this easier?
Comment #3
infojunkieConcerning the per-field access control issue: yes, the CCK approach would be best. Packaging the rendering options as a field formatter would allow for future extensions.
Concerning chart rendering, this is also on my roadmap.
However, bear in mind that some cell values are calculated on the fly by the SocialCalc (JavaScript) engine. Although these values might be cached and stored in the database, the real values can only be obtained by running the client-side engine.
Comment #4
infojunkieClosing old issues. Reopen if needed.