Editor is not setting id on server packet

lonnien

I was able to work around that for insert since I always use id as the tag for my pk. BUT when it comes to delete, the pk is essential and the server only gets the following (using debug to show and copy $_POST).
array(4) (
[action] => (string) remove
[table] => (string) form_products
[id] => (string)
[data] => array(1) (
[0] => (string)
)
)

I have tried to follow the examples but when I use the mDataProp I get a - Requested unknown parameter 'id' from data source for row 0. This seems to solve and run OK when I change the entry "mDataProp": "'.$colname.'", to "mDataProp": "'.$i.'", which is the loop counter. The table fills in, server side works, pagination, column sort and Editor all work EXCEPT for deletion.

Since I am not using the DT built in database classes is there a way for me to tell the Editor which column is the primary key so it can pass it to the server?

allan

Editor requires that the ID be set for each row in the table as this is used to identify the row. It is normally the primary key concatenated with some other string to make it a valid DOM key. The way I'd suggest you set an ID for each row is to use the DT_RowId "magic" property like the examples do:

[code]
{
"DT_RowId": "row_1",
"engine": "Trident",
"browser": "Internet Explorer 4.0",
"platform": "Win 95+",
"version": "4",
"grade": "X"
},
[/code]

Allan

lonnien

I have done that and no change for anything. I think all that does is tell Editor which Table row to use for display and editing. That part is already working great (I can update and insert), as I said I can do everything except delete which requires that Editor return the PK. The [id] field from my debug capture should be set the value of "some" field in the Editor but is empty when sent to the Server and I need to be able to tell it what that field is. With my design convention the PK is always the first field and called id.

Any ideas?

lonnien

The server only gets the following (using debug to show and copy $_POST).
array(4) (
[action] => (string) remove
[table] => (string) form_products
[id] => (string)
[data] => array(1) (
[0] => (string)
)
)

If the [id] could show the value of the PK from the Editor fields or the data array [0] had the entire record I could extract the PK and do the deed.

allan

In a delete action, the `data` array contains a list of the DOM IDs (which as I say are typically made up from the primary keys, assigned through DT_RowId) - see the data sent in the delete example at the bottom of this page: http://editor.datatables.net/server/ . Are you not seeing the DOM IDs being sent in the `data` array?

Allan

lonnien

OK, I got it figured out. I am using only server side processing and had to add the DT_RowId to the returned data. I had been following examples that are tailored to local processing. Delete works as expected. Thanks for the help.

allan

Excellent to hear that you got it going. I'm going to create a server-side processing example in the next major release, but if you have any suggestions about what you found confusing, I'm all ears. Feedback is very welcome so I can reflect actual usage in the product.

Regards,
Allan

lonnien

I'll post some thoughts over the next few days. It was totally confusing and nearly impossible to the point I considered using a simple form editor I have already done in PHP, BUT it is amazing how simple the whole thing is when all the stars line up. Partly it is my problem coming from a straight C and dBase background and having recently cut my teeth on PHP, sql and web based programming. It makes my head hurt to look at javascript, especially when a wizard has done the code. You are a great programmer, but perhaps you are too qualified to teach your ways to us. We need some base code that is so simple even I could understand it, and then work into the object oriented name space stuff. I look at that and fail to see any semblance of a real program but it seems to work, so it will be worth the effort to learn it.

Anyway, thanks again. This is sweet code and the Editor works like a treat. Well worth the money and time invested to learn it and get it going.

allan

Heh - thanks for the feedback. Very much appreciated!

I'm planning of updating the examples fairly significantly in 1.3. There is a lot of information already there, and a lot that is effectively hidden - 1.3 will have a better layout showing the various components of how Editor works, which will hopefully help in getting a grounding with Editor.

Regards,
Allan