Some lessons learned (server side, editable, fnrender, fancybox, etc)
Some lessons learned (server side, editable, fnrender, fancybox, etc)
Here's a short list of lessons I learned (the hard way) in the past several days
1) Be careful with fancybox or other popups that you run within your page - if those pages include jquery, you'll clobber your original jquery instance and any of the plug-ins you loaded into it. This is very "duh" but was hard for me to debug. I like having jquery in my pop-up pages so I can test those pages independently, so I've added parameters to the php file that allows disabling including the jquery inclusion script tag, for when I call this page from within a page that already has jquery running. I start my data caching in fnServerData, which means you have to customize the server call.
... fnRender ...
2) For whatever reason, I thought that fnRender just affected the cell display html, and that datatables kept your original data intact in it's internal structure. I think it should, or at least have an object with the original values. I can create my own cached values, and intend to do so in some plugins or code, but if various implementations start caching the values, you may end up with memory bloat or overwriting the cached values many times. how does bUserRendered work? that seems to imply that datatables has the original values somewhere...
2a) fnRender affects editable, obviously. if you add html code with fnRender, you might want to cache the original values for use with editable (you can set the value with the "data" member of your editable initialization.. but you also need to re-apply fnRender after your edit - you can use the editable intialization "callback" member. or perhaps fnDraw the entire table again, which will refresh data from server side if you're using server side. [I'm trying to remember why, but my repainting routine kicked off the Processing text, so run $('.dataTables_processing').hide() in that routine..]
2b) avoid fnRender on your id column (for server side processing). not only are you changing the cell contents, but the TR id is being changed too. I was adding a deletion image and link to my ID column.. bad idea. Create a new column for custom items like that.
2c) fnRender runs before the TD is added to the DOM, so you can't access it at that point (i.e. to add a class to it). use fnRowCallback for that, since that runs later.
1) Be careful with fancybox or other popups that you run within your page - if those pages include jquery, you'll clobber your original jquery instance and any of the plug-ins you loaded into it. This is very "duh" but was hard for me to debug. I like having jquery in my pop-up pages so I can test those pages independently, so I've added parameters to the php file that allows disabling including the jquery inclusion script tag, for when I call this page from within a page that already has jquery running. I start my data caching in fnServerData, which means you have to customize the server call.
... fnRender ...
2) For whatever reason, I thought that fnRender just affected the cell display html, and that datatables kept your original data intact in it's internal structure. I think it should, or at least have an object with the original values. I can create my own cached values, and intend to do so in some plugins or code, but if various implementations start caching the values, you may end up with memory bloat or overwriting the cached values many times. how does bUserRendered work? that seems to imply that datatables has the original values somewhere...
2a) fnRender affects editable, obviously. if you add html code with fnRender, you might want to cache the original values for use with editable (you can set the value with the "data" member of your editable initialization.. but you also need to re-apply fnRender after your edit - you can use the editable intialization "callback" member. or perhaps fnDraw the entire table again, which will refresh data from server side if you're using server side. [I'm trying to remember why, but my repainting routine kicked off the Processing text, so run $('.dataTables_processing').hide() in that routine..]
2b) avoid fnRender on your id column (for server side processing). not only are you changing the cell contents, but the TR id is being changed too. I was adding a deletion image and link to my ID column.. bad idea. Create a new column for custom items like that.
2c) fnRender runs before the TD is added to the DOM, so you can't access it at that point (i.e. to add a class to it). use fnRowCallback for that, since that runs later.
This discussion has been closed.
Replies
[quote]fbas said: 2) For whatever reason, I thought that fnRender just affected the cell display html[/quote]
fnRender will also change the data held internally - the reason for doing it this way is so you can filter on what you can see, rather than what you can't. For example if you format "1000" into "1'000" you can search for "1'000" (possibly a poor example since you might want to leave it as 1000 - but that's the idea :-) ).
You can overrule this by using the bUseRendered flag and setting it to false. This will mean that the data held internally is no altered and only the HTML output is "rendered".
[quote]fbas said: 2b) avoid fnRender on your id column (for server side processing)[/quote]
Yup! Actually using mDataProp is quite nice for server-side processing since it can abstract that kind of issue away and you don't need to have hidden columns for meta data.
Nice tips! Thanks for sharing :-)
Regards,
Allan
this is a pretty significant thing for editable cells where fnRender added some markup (i.e. a column with an image url that you want to display as that image). The "highlight search terms" code I want to implement will use fnRender but will need to get the original data/strings.
I can see a case where you might want to have rendered values used for some functions, but not others, but I can live with this constraint.