Hello,

As I understand you plan on releasing it as a separate content type? How about releasing it as a CCK field so that it can be inserted into other content types, this seems to be the way forward to Drupal.

Also, does it store the table in a single field, given as I understand this is an input filter for a textarea? That would be the best IMHO :)

CommentFileSizeAuthor
#7 nodetable-edit-screen.png17.82 KBjohn.kenney
#7 nodetable-editrow-screen.png16.8 KBjohn.kenney
#7 nodetable-editrow-screen_001.png23.94 KBjohn.kenney
#7 nodetable-editrows-screen.png21.39 KBjohn.kenney

Comments

giorgio79’s picture

giorgio79 commented

Hmmm, it seems there is already something for CCK

http://drupal.org/project/tablefield

john.kenney’s picture

john.kenney commented

this module can insert tables into any content type via a filter as [nodetable: tableID]. the filter inserts a complete table anywhere you want. It can even be put inside a CCK field.

the module also generates standalone pages in a unique content type. you can do anything you want with this content type, including adding CCK fields to them.

for my own sites, I can't see how the tables being a CCK field would work at all. i'm no CCK expert, so perhaps it could recrafted to both do what i need and be a CCK field at the same time - or maybe it already is for all I know. however, if CCK Tablefield and CCK Matrixfield are any indication of what that would look like, then I'd say it is not possible.

i don't believe the table is stored as a 'single field'. again, i'm not the technical guy, but as i understand, the HTML tables are stored across 3 DB tables in various arrays for technical reasons that are beyond me. the developer can better answer this question.

in terms of CCK tablefield. i have tried this module and it doesn't come close to doing what i require for my sites or what the predecessor module (TableManager) we based this on does.

Tablefield is one of several alternatives for handling HTML tables, I have tried them all. See this page for a comparison of them: http://drupal.org/node/619014

if you have more specific ideas about this CCK angle, please share.

giorgio79’s picture

giorgio79 commented

Thanks John, indeed pretty much all D6 table modules have very poor functionality at the moment.

There is a fundamental difference between the CCK Tablefield and Tablemanager:

In Tablemanager, on the node edit page you have to enter a weird filter format sg like [tablemanager:213, 123345, TRUE,FALSE] whatever, which I don't want my users to have to go through. Once saved, the table can then be edited on the node view page, which I think is not ideal...

In CCK Tablefield, users enter data in the table while editing the node and on node view page they just observe the table.

Also, technically, CCK Tablefield is stored in a single field inside the content table which is great for performance (assuming you have 1 instance of a tablefield in the node). But if you have a module spreading out in several tables (which will need to be JOINed in SQL) and they are big you will pay an arms and legs for hosting and db admin fees if the site turns out to be a true success with massive traffic.

Content in a single table is the fastest .I am going for tens of thousands of users of course with a new site.

At the moment I plan to add functionality to CCK Tablefield, namely this one:
http://plugins.jquery.com/project/tableAddRow

Here is live demo (this adds rows at the end of table)
http://cloudgen.w0ng.hk/jquery/table.addrow.php

This is what is missing, (plus disabling the table rebuild functionality)

Will be interesting to see how this module works though, the screenshot looks nice.

john.kenney’s picture

john.kenney commented

right, everyone has different needs and the needs of the sponsors/developers drive the design of this module like any other module. for instance, i don't have users touching tables directly, so that isn't something i think about. the other sponsor, i think he does have users editing the tables, if i'm not mistaken. on the other hand, i do need .csv importing and extreme flexibility in table/cell styling, so i think about those things.

also for both myself and the other sponsor, our tables and traffic are small, so scalability hasn't been a factor we've considered (and i don't think TableManager has either). it has been mentioned as an issue and, again, the developer may have more to say on this. i really don't know what i'm talking about as to how the data are stored.

in terms of editing features, what we've got so far with NT is very nice. it has add/edit/delete feature taht looks not unlike what you pointed me to. but like TableManager, the table edit is done on it's own page. not embedded within the display node - or at least that's how i use it.

alternatively, you can make the table node be the actual display node in NT and not use the input filter. you can't do this in TM, but NT structure is different and allows this. so, if you can fashion the content around the table within the NT node, then you have the table and the content editable on the same edit form. i haven't done this to a great degree myself, but if need be, you could surround the table above and below with whatever fields you want via CCK and contemplate. for my purposes, i am always pasting small tables inside other content in all sorts of different ways, including collapsible fieldsets, so a fixed structure like this would not suit.

also, regarding the input filter. in TM, it does have complex formulations like you've written, but generally it is simply: [tablemanager: tableID]. same how nodtable works. anything beyond the tableID is for sorting and filtering and paging of the data meant for large tables. i have no idea how widely used those things are - or if they even work.

if you don't mind wading thru some bickering, you can find a recent copy of the NT code here: http://drupal.org/node/772790#comment-2857448. this is definitely a work in progress though, so use only on test site. it mostly works, but there are a number of punch list items remaining - for instance, some of us can't get the import working while some other can. and some of the editing/sorting features are fully done. but it otherwise looks about as it will.

any feedback on it would be welcome.

giorgio79’s picture

giorgio79 commented

Thanks will be checking it out later today or tomorrow.

giorgio79’s picture

giorgio79 commented

Just installed it but I have been unable to figure out how to add new rows. I successfully added a header row but that is about it. When adding a new row to the table the entire page seemed to refresh which was weird.

The functionality looks pretty much like TableManager 6 dev so I guess I will revisit this one when a stable release is ready.

john.kenney’s picture

john.kenney commented
StatusFileSize
new nodetable-editrows-screen.png21.39 KB
new nodetable-editrow-screen_001.png23.94 KB
new nodetable-editrow-screen.png16.8 KB
new nodetable-edit-screen.png17.82 KB

yes, it is very similar to TM. and waiting for a stable release makes good sense, of course. we aren't exactly moving at light speed here, so it could be a little while.

i'm not sure why you can't add rows. that functionality has never been an issue for any of us.

do you have tabs that say 'add row' 'edit rows' on the nodetable view? see attached images.

since i'm one of the people who can't get csv import to work, all i can do is manually create tables and i've never had a problem with doing that.

anyway, sorry for the bother. i appreciate your taking a quick look.

giorgio79’s picture

giorgio79 commented

Hi John,

Let me rephrase, I can add rows as admin. What I have yet to figure out it how to enable users adding rows when viewing a table.

john.kenney’s picture

john.kenney commented

did you try enabling user permissions? this allows me to add rows as anon.

but you point up something that's missing and that's the ability to edit the entire node, not just the table in the node. permission option for that appears to be missing. i'll put it on our punch list.

thank you for the feedback.