My team and I are developing a java web application which allows our admins to create and edit "methods" which can later be viewed by other users.

We are currently discussing the best way to implement this and aim for a screenflow similar to creating / editing events in google calendar.

I.e. The admin starts on a page which shows all current "methods" and a "create new method" button. If he chooses to edit a "method" he is redirected to page "EDIT" where he can change the method's attributes (editing and then sending it via AJAX to update the attribute). If he chooses to create a new method he should be redirected to a page looking the same, changing attributes, etc. But if he does not change anything and goes back / closes the browser the method should not be saved.

We currently have 2 ideas to do this, both with some drawbacks:

A) Create the "method" with default values and redirect the user to the edit-page. Drawback: Should the user go back or close the browser, we have created an unnecessary entry in the db, which our product owner would like to avoid. (There is a 'delete' button, but this would require another action by the admin)Idea A screenflow

B) We create separate pages for create and edit (and the corresponding handlers). Drawback: We have to create and maintain 2 (or even 4) files which do basically the same thing.

Is there any way to negate our drawbacks or another alternative how to implement this? We are using Java Web Projects, JSPs and Servlets as technology.


Can you create a dummy record in the database with the default values, then pass a flag to the edit page to indicate it should create instead of update on save? If it's not possible to pass a flag, would it be possible to give the dummy record a unique ID that you would then hard-code into the edit page to indicate that the record should be created instead of updated?


This is a common problem we encounter in our tools too. A nice UI solution we use is shown by a product by Telerek called Kendo. The grid can use a button to sync edits with the db inside the grid. Although the grid takes a professional license, you can try it out free and see if you like the style and follow the samples and build your own instead.

Basically, the data is shown in an HTML table, if the user clicks on the cell it goes into an edit mode to alter values directly in the cell. If they do not want to save the edit or simply close the browser, the value was only in the client browser and is thrown out. Optionally, edits can be sync'd live as the user moves between fields. It's up to you how the interface functions. The data is actually stored in a smart array in the browser like a small database where the grid is just displaying the array (MVC, Model View Controller design pattern). Click save just sends the dirty cells to the database via ajax.

Check out: http://demos.telerik.com/kendo-ui/grid/editing-inline

Even if you don't user their tools, the method is a great demo on how to manage the UI for table edits.

  • Thanks, we really like the idea of a editable table but since we have a lot of fields and offer our admins to upload files for one table entry this solution would create a very wide table. (I.e. we pretty much need a web-page to edit a single entry only) – Nijin22 May 29 '15 at 11:07

I'm not familiar with the particular technologies that you're using, but maybe I can offer some advice.

If I understand you correctly, you have two identical User Interfaces (views) with two different behaviors. This tells me that you only need to have one view, but two controllers. When your user clicks "new", the view is shown with a "Create" controller that tells it how to behave. When the user clicks "edit", they're shown the same view with an "Edit" controller that behaves a little differently.

This saves you from coding two different UIs. You only have to maintain the logic that dictates how they behave.

I recommend reading up on the Model-View-Controller pattern for more information.

Your Answer

