Styling cells

Hi, please try this (it's from my own development version) I seem to remember spotting this once before.

If it fixes your issue please let me know and I'll roll it into the D6 version on here.

Thanks,

Pobster

Fantastic!! Thanks very much. I appreciate your responding so quickly.

Applied the patch and that solved the cell classes nicely - once I got the format for fields done in right way.

Now class filter works on .csv import and/or direct editing of a cell in admin view.

Seems to have possibly caused some side effects though:

- Now when you view the entire table in admin, all the cells say 'array'. When you > edit a cell, the actual values are displayed properly in their fields, but when you go back to the admin table view, the cells still all say 'array' again. On the front end, the cells display properly with classes applied, so this is just affecting the back end.

- Now the header row is creating a new record/row at the bottom of the table. I don't believe it did that before. This is when importing to an existing table with box checked for 'use first line as HEADER'. I understood that that row would be ignored in an import for an existing table - and it seemed to be so yesterday before the patch, but possibly it was happening then and I didn't notice.

If you are able to fix, that might be helpful, but usable as is.

Couple additional notes about formatting as an fyi to other module users:

- With <a> tags, they only worked when i removed the quotes. This is probably true for other HTML, too. I guess the module inserts quotes anywhere they are supposed to be, both for class variables or for regular HTML in the content. So, for example, this field content works <a href=/company-review>read review</a>[class=reviewed] and this didn't <a href="/company-review">read review</a>[class=reviewed]

- Also, the class filter does not like hyphenated class names. So this worked YES[class=recoyes] and this didn't YES[class=reco-yes]

- The class filter does not support multiple classes, so, for instance, this didn't work: YES[class=center recoyes]. Nor did alternate versions with single or double quotes

- With class filters in cells, module appears to support only 'text' type. Actually, if you are importing a file, everything works fine even if you use, say, 'numeric' field -- at least until you directly try to edit a record/row in tablemanager, then it won't let you save the record until you delete the non-numeric characters from the field which means you've lost your styling.

- Since I had to create multiple tables to test these things out, I realized that while the module auto-generates a unique ID for each table, this selector isn't going to stable enough to style against in many cases. So I wrapped the whole table inside a div with a unique class and adjusted CSS accordingly. This allows the table ID to change however without further tweaks to the CSS.

All above can be worked thru once you know it works this way.

Ah apologies I cut out a whole load of stuff from the patch because I'm not keen on releasing untested features and there was all sorts of other stuff mixed in, I bet I've just been a bit over zealous with my snipping! I'll fish out the rest of what needs changing (by the end of today)...

You raise some good points, especially with the multiple classes - I wrote that regular expression a long time ago now back when I was still learning php, I'm sure I can do an awful lot better now ;o)

The point about quotes being converted is a known issue that I've not really been willing to fix in the current 6.x-1.x version as it's a fundamental issue of the stored cells being passed through your Drupal filter when they should be stored as-is and displayed through the Drupal filter... It's a misunderstanding I had with the way Drupal api expects to handle these types of things and I would fix it... But the 6.x-2.x version is nearing a RC version and it seems silly to go fixing things in the 1.x version when it'll be obsolete soon. I just wish I could get the 2.x version done sooner - I keep getting paid work to do which obviously takes precedence!

Pobster

Well there are some glitches, but it works pretty good as it is - at least for my purposes. The 2.x version you mention sounds pretty good. Not sure what all is in it, but I'd be willing to contribute a modest sum if it helps move things along. If this is of interest, perhaps we can discuss via pm. Either way, thanks for all the work on the module.

Apologies unstitching my changes has proved to be a little more complicated than I imagined! Obviously now it's Monday and I'm not going to be able to do much during the week - I can make no promises!

Pobster

Alright. Understood.

When you have a chance, the thing that would be most helpful to get fixed is the part where 'array' is printed in the table cells in admin view.

Other items can be worked around.

Thanks for your efforts on this.

John

I did some progress on the array displays, these are fixed now. I rewrote the rendering of the table in the tablemanager_admin module a little bit in so it was easier to understand what is going on there. I know I removed the ordering of the columns, I will re-add that functionality later on. For now it was easier to remove it, and clean up the form and the theming. I also cleaned up the pager a little bit, using the core pager functions, but that needs a bit more testing.

I was wondering how we could fully utilize the node system. It seems like a major rework, so I am not going to attempt it, but it might be worthwhile to do it later on - node table could provide the data we currently store in the tablemanager table and tabelamanger_data could be the special table storing the tables.

Apologies for not posting sooner but it's actually my birthday today and so I was out last night and for pretty much all of today...

Anyways, just a quick pointer;

I've already mostly written a branch two of Tablemanager which does use nodes so please don't waste any of your time looking into achieving this as it's already been done.
Be careful with the ordering - it's actually a lot trickier than it looks because of the stupid serialized arrays. They're all done away with in the 2.x version!

Thanks - and good work so far!

Pobster

Oh I see. In that case i'll hold off on this, because i will most likely implement things that you already have done. When do you think you'll share the code? I could help you out in making it stable.

It's temporarily a little complicated I'm afraid as I implemented an early version of it on (UK) Channel Fives corporate site so I'm unsure of whether I can actually share it or even release it or not at the moment... In it's current state right now (that was a year ago) it's more or less complete anyway, it just needs a little touching up here and there - but there's certainly no show stoppers, only a few more things on my own wishlist, a couple of small-ish bugs and a feature which I've decided to remove. I just don't really have enough free time at the moment to do it myself and I'm not convinced it's the sort of stuff I'm comfortable with doing with someone else remotely, I prefer a closer working relationship especially as this is quite an important module to me.

Pobster

Could you describe what has changed in the 2.x branch so that we see if we could actually reach our goal with this module? And if we could, would you find it doable to open up the code, publish the list of TODOs, so i can go in, roll a patch, and then you only need to do a review. This would save your time and you stay in total control of the code.

It's not as easy as that, as I mentioned above - I'm going to need to check with our works legal department, tbh it's the main root of why I'm so easy convinced to drag my heels over developing 2.x - I can't just release code which has been used on clients projects, it's obviously not an easy position to be in. I'd forget about it for the time being but if you're really interested - there's many details about what's new in other issue queues.

Pobster

Ok, so basically you are saying that the code was developed for and, therefore, is owned by your company's clients -- or that such ownership/rights are so heavily in question that you can't release without legal approval and without legal approval, it can't be released as open source module in drupal. I can understand that situation - client pays for work, work gets done. End of story.

What I can't understand is how that might be resolved in a way that would result in it getting posted on Drupal. If it has been a year or more that it has been in place and in use at client sites and not released publicly, then it sounds like that is simply never going to happen. I'm no lawyer, but I suspect that the very fact that it has, for an extended period, been in such use and not been released publicly validates and reinforces that it is not open source and that your clients and/or your company own that code. And that the legal effort to ensure it's release under rock solid legal conditions is going to be more work than anybody is going to want to do.

My conclusion, to be blunt, is that the 2.x version - or at least the code as you've written it - will never exist as a drupal module. And, further, it sounds like you as a person probably cannot write replacement code because it would entail borrowing (aka stealing) your client's or your company's IP. Perhaps I'm overreading this and continuing to be too blunt, but seems to me this creates a largely impenetrable barrier to progress with this module. It can't go anywhere without major rethinking of the path forward and/or the staffing of the module.

The options as I see them are: 1) you add another developer to the TableManager team and he builds the 2.x code base largely from scratch, perhaps with some guidance from you as to reqts, but no code. or 2) such developer starts a new module that borrows what it can from this module, but that largely rebuilds the 2.x code (or similar feature set) from scratch. These are, effectively the same option, it just depends on whether done inside existing module admin or a new module admin and what/if you want to play a role in it.

I know you've worked on this for a long time and have achieved a great deal -- the basic functions of the module are excellent and it's potential is even better. But encouraging us all to be patient and so forth, doesn't help those of us that have to get on with things now. If your module can't now or won't soon do the job, then we need to go elsewhere. I think that continuing to suggest that something big is just around the corner, isn't doing anybody any good.

No not at all, that's why I'm saying this is a grey area. The code wasn't developed for Five, Five are actually using a bastardized version of 5.x-2.x which never saw the light of day to the public - the problem is that the functionality is the same (and the schema) all I'm saying is that I'd do better to check first - I can't just release the code whenever I like when it's my livelihood involved. You have someone happily finishing the 1.x branch - why are you bothered about the 2.x branch at all? There's more work involved finishing 2.x than there is with the 1.x branch? Surely if you're paying for it, that option makes more sense?

Pobster

ok, paul, i love your module - it does great things, but having built the foundation and opened our eyes (or at least mine) to the possibilities, you can't ask us to live with semi-functional code that isn't evolving. no official D6 version 22 mths in? most other such modules are long presumed dead.

but Tablemanager does good things - it shouldn't die. some of us need your functionality to do our jobs. we need it right now.

i certainly understand that you need to check before you can release the code, but the question is: are you definitively saying you are going to check?

if so, when are you going to check? next week? next month? how long would it take to get a concrete answer?

if you do check and get approval, then what? when would the 2.x version be available?

and if you check and you can't get approval, what then? how will you move the module forward? will you move the module forward? or will it have to be abandoned?

perhaps i'm a pessimist, but my sense is that the legal issues are going to prove intractable - or at least that overcoming them is more work than anyone is willing to put in. that could be wrong, but sounds like that's where we are: a dead end.

but if that is wrong or if there is a path to knowing for sure, i guess the key thing for your community of users is to know that we are moving down that path with some velocity - that a plan that is actually unfolding, a plan that has milestones. absent such plan, it feels like we are being asked to go on indefinite standstill with a piece of code that doesn't really work.

but it all hinges on you, sir. what is the plan? if there is no plan, then please just tell us straight out and we can figure out where to go from here.

also, sorry, but to answer your actual questions more directly vs. just throwing questions back at you. here's the scoop:

we aren't able to actually implement all the functionality that is supposed to work on the .dev. specifically for example: we can't get the add / delete / reoorder columns working. or rather, that to do so would involve considerable remodeling of the module that isn't consistent with our initial budget and/or that having done all that additional remodeling (which requires implementing some/much of your 2.x), does it make sense to simply stop there - we'd want to use that revamped platform to move forward to a 'real' 6.x version, let alone a soon necessary 7.x version.

maybe you could get the .dev version working properly on the cheap cause you know the code better, but with the resources available to us right now, we can't.

that is why the question of the future is important - whatever patches we put onto .dev aren't going to satisfy anybody for very long. we need to know where and when you are going to take this module.

---

since writing these earlier comments, I've been thinking about this some more. i think for me, i can't deploy the module without knowing more about the development path. i've got two dozen sites right now where i want to put this module. perhaps 200 sites by this time next year. probably 1,000+ tables deployed across them. somewhere in there, they are all going to roll over to D7. doesn't feel like this module is going to be the solution for that.

and then one final point to reiterate is that, as you know, both Andrew and I are prepared to put money against this. and we've found a good technical guy who seems to grasp the workings of the module very well. i'd like to think we can all work together to bring the module to the next level.

let's move discussion of these discussion points to a more appropriate thread: http://drupal.org/node/234139 which discusses upgrading module to D6.

there are many people subscribing on that thread who may be interested in participating in this discussion.