Grid of checkboxes represents a many-to-many db relationship; the best way to get from webform to database

I am using jquery/jsp/java ejb3.0/sql server.

The User interface requirement (a jsp page) is a grid of checkboxes, ~10 rows high and up to about ~30 rows wide (this varies), it represents a linker table for a many-to-many table relationship.

The checkboxes will be populated from the database (if row present in linker table, then checkbox is checked).

The user can then check/uncheck whichever, as many times as possible. On submit any changes should be saved to db. The changes will consist of deleting a row if unchecked(and if checked/row present before), and inserting a row if checked (and unchecke开发者_运维知识库d/no row present before).

My problem is, what is the best way to implement this ? Using ajax to update database using checkbox onchange event is not appropriate. I want it to be a submit form event.

I'd try and decomplexify the situation by taking a step back and introducing a simple bean to represent the "metadata" - i.e. the 300-or-so true/false values.

Actually, when dealing with that many fields, you'd probably use a mother-bean containing child beans which hold conceptually-related fields together. e.g.:

public class MotherBean {
    private UserSettingBean userSettingBean;
    private UserRelationshipBean userRelationshipBean;
    private UserPreferencesBean userPreferencesBean;
    ...
}

So your "web tier" becomes a straightforward CRUD controller for the MotherBean; the sort of thing that gets done every day. You could even use something like Spring Roo to build up the scaffolding for that.

Then, when you pass that bean down into your lower layer(s) (you may or may not have a traditional "service" or "business logic" layer in this design), you have a DAO that translates the relationship metadata into the actual many-to-many relationships. Given the number of fields we're talking about, I'd again suggest to delegate out this work into sub-DAOs (for want of a better term) that deal with related links.

Obviously, the "get" path is the same thing in reverse. You ask the MotherBeanDAO for the metadata related to user 1234, it asks its delegate DAOs for the child beans, wraps them up and the resultant MotherBean gets passed all the way up to the web front end.