I have a list from query that populate checkboxes (checked) in a form.
However, when a user deselects some of the items from, I want them to be deleted from the database for that user.
Here is the ex: this is how the form looks like:
Item 80 626
1. HS # 1 (87) chk chk
2. HS #2 (59) chk chk
This is the list of items already n their preferences (db ids)
80|87, 626|87, 80|59, 626|59
Now from a form, if they deselect one of the items (80|87), I want it to be deleted from the database.
Like these, DELETE FROM ITEMS_TBL WHERE ITEM_ID = 80, Category_ID = 87
How can we do it? Can we check ListContains or something else?
Let's say your query contained 5 records, ID's 1-5. When output, the user unselects ID 2 and 5. When they submit the form, you want to delete IDs 2 and 5 right? But since they are not selected, their IDs are not available in the FORM scope, correct?
What I would do is run the same query on submit, but add an addendum that uses a ValueList() on the FORM variable that holds the selected IDs. Like:
WHERE ids NOT IN (#FORM.ids#)
That would basically get you back a query of record IDs that are up for deletion. Then you could run another query right after it that goes:
DELETE FROM tableName
WHERE IDs in (#ValueList( firstQueryName.ids )#)
it would be a lot easier to do it the other way round, have a checkbox for records you want to be deleted.
Or have a delete button and do it realtime in ajax.
The only issue with using a hidden form field is that users can modify this value before it is submitted. So you'll have to do extra cross checking to ensure that the IDs that are there are ones that were initially displayed or that the user had access to delete regardless.
Aegis, sorry but you are wrong, all/any form field can be edited before submission, a hidden form field is no different to any other. There are even browser plugins which do it for you, you should most definately check up on this if you think it is not possible.
Actually, no, I'm not wrong. My suggestion is to do sanitization checks on all incoming data BECAUSE client-side data can be modified. My suggestion is to not take the data presented at face value, but to ensure you always double check that what is provided is valid. Nowhere in my post do I say that it's not possible. My hint indicates that just because you put it into a hidden field, does NOT mean that it cannot be messed with before it is sent back to the server. Many developers have a mindset that hidden data is not exposed to the user for modification as easily as an input field.
Aegis, you said "QUOTE"
The only issue with using a hidden form field is that users can modify this value before it is submitted.
My reply was that this can be done with ANY form field, not just hidden.
You then said: "Not at all."
If you're going to quote, quote the WHOLE post. Because the second line "So you'll have to do extra cross checking to ensure that the IDs that are there are ones that were initially displayed or that the user had access to delete regardless." is the subject behind my reasoning.
It does not state that putting information into a hidden field is not a possible solution. It just iterates that checking that data before assuming it is processed is a wise course of action, as many new developers often make the assumption that a hidden field cannot be modified.