I’m using jQuery autocomplete control to perform search on three entities: Owner, Manager and a Tenant. Every entity is saved to its own table in the database.
Under the autocomplete control, a grid (hidden div) will be shown and populated based on the user’s selection. The grid uses textfields controls so the user can edit and save again.
Now, I’m having these problems:
- When submitting back to the server, how to know which entity the
user worked on? is it Owner, Manager or Tenant? I need to figure
this out in order to know where to save the data in the database. - Server side validation is a must as you know. What to do if the user submitted invalid data? The common pattern is to redisplay the page again with error messages.
But in my case the grid/div is shown based own autocomplete search, showing the page again is simply going to hide the div.
Could I employ a much easier approach any way?
Technologies used are jQuery and Grails framework.
There’s a lot going on here, but it’s not overwhelming. Tackle it bit by bit.
Obviously the initial query could use joins to get all results from the three tables that match the specified query values. However,I’d begin by questioning your rationale behind the three separate database tables, as it breaks the basic tenet of a relational database–repeating fields and possibly repeating data if one person fills two different roles (a classic: “not likely, but in theory possible situation”) Each is a person, and each will have similar data requirements such as first name, last name, address, city, etc. So, why not store “person” information in a table and then either have a separate table that defines a person by id for the relationship or alternately has a field in the “person” database that defines their role? Ultimately, for this to work you have to have some sort of common identifier that the system can look at to tell it what role the person holds.
If you are to stay with the existing structure, I’d imagine you’d have to do a complex join that aliases the ID’s from each table as a fieldname like Owner_id that you could then use to base your decision on what table they belong in….not efficient!
I’d personally query the information into jQuery Datatables, which is currently the most feature-rich grid out there. It does have editable regions available and working well. The trick to this on the UI side is to initialize the datatable with an empty resultset coming from the ajax source initially and then “refreshing” it with with the command
oTable.fnDraw(false);Finally, for the save I’d take the ID of the saved value and jQuery Ajax save it to a script. I’d run a lookup via the DB on that ID to see what relationship it has, and this is where better normalization would allow you to simply query based on their relationship status (owner, manager, or tenant) to get that value. From there, run a DB update based on the calculated ID and tablename and cycle the view to both indicate success and return to a “main screen”