Best Practices for Struts 2 CRUD

So I've found a bunch of Struts 2 CRUD examples around the web:

Struts 2 CRUD Demo

and a few books:

Apache Struts 2 Web Application Development ISBN: 978-1847193391

Struts 2 Design and Programming ISBN: 978-0980331608

But all of them differ a little bit on how to do form population.

Some suggest implementing the Java interfaces ModelDriven or Prepareable to call come prepare function to pre-populate any needed data members.

Others suggest creating your own PrepareForUpdate action that calls a pre-populate function then redirects to the main edit view.

They also very on how to pass around an object identifier to indicate what object to retrieve for editing. SOme suggest intercepters what others throw it in the URL parameters and retrieve it through ActionC开发者_如何学JAVAontext or pass it around through a s:hidden field.

Is there a Best Practices way to do form population in Struts 2?

What are the advantages/disadvantages to the methods mentioned above?

I'm not aware of any documented best practices, but I've been using Webwork and Struts2 for about three years now, so I can tell you what I've used in my projects. By the way, the CRUD demo documentation you linked to strikes me as a bit out of date (I realize its from the project site).

I split my CRUD work into three different actions:

• An action that lists the entities. It supports pagination and populates some type of a table or grid view.
• An action that handles both add and edit functionality. Uses a prepare() method to set up dropdowns, etc.
• An action that handles delete functionality.

Some suggest implementing the Java interfaces ModelDriven or Prepareable to call come prepare function to pre-populate any needed data members.

That's the approach that I would advocate, although I don't use the ModelDriven interface. For details, check out how Struts2 ModelDriven interface works and the comments on my answer. Whether you use ModelDriven or not is just a personal choice. Also, check out why is model-driven action preferred over object backed bean properties.

Others suggest creating your own PrepareForUpdate action that calls a pre-populate function then redirects to the main edit view.

I have not seen that before and based on your description, I would avoid that technique. It seems wasteful to do a redirect and create an additional HTTP request to achieve the same thing that the prepare() method was designed to handle.

They also very on how to pass around an object identifier to indicate what object to retrieve for editing.

Just pass the identifier in the URL or the form. That's the standard approach for web applications.

I've been using Struts 2 for about 3 years. I use ModelDriven and Prepareable together in the same action. Each domain object (model) has a struts action class that returns a list or single object depending on if the id was passed to the action. This works pretty well for me, and the only time it's been problematic is when using Ajax. I usually separate my Ajax actions into a separate action for the model, if I am using them. I store the model id, as well as any related objects that I might need as hidden HTML fields in the view.

Using this approach, the action and the view are restful. You can leave the page for a long period of time and invoke the action without fear that the action will fail. Here's an example:

public class ApplicationAction extends MyBaseAction 
implements ModelDriven<Application>, Preparable {

    private static final long serialVersionUID = 7242685178906659449L;
    private ApplicationService applicationService;
    private Application application;
    private Integer id;
    List<Application> allApplications;

    public Integer getId() {
        return id;
    }
    public void setId(Integer id) {
        this.id = id;
    }

    public Application getModel() {
        return application;
    }

    public void prepare() throws Exception {
        if(id == null || id.intValue() == 0){
            application= new Application();
        }else{
            application= applicationService.getApplication(id);
        }
    }

    @SkipValidation
    public String list() throws Exception {
        allApplications = applicationService.getApplications();
        return SUCCESS;
    }

    @Validations( visitorFields = {@VisitorFieldValidator(message = "Validation Error", fieldName = "model", appendPrefix = false)})
    public String update() throws Exception {
        applicationService.saveApplication(application);
        addActionMessage("Application Saved Successfully.");
        return SUCCESS;
    }

    public void setApplicationService(ApplicationService applicationService) {
        this.applicationService = applicationService;
    }

    public List<Application> getAllApplications() {
        return allApplications;
    }

}