Databases
StackOverflow2013
Postsdbo
PORead only fields in spring-roo or spring-web-mvc
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PORead only fields in spring-roo or spring-web-mvc
    primarykey
    data
    text
    <p>I have what appears to be a common problem within spring-mvc. Several of my domain object have fields that are not updatable so in my view I am not binding these fields. <em>For competeness sake The way these are excluded from the view is by editing the spring-roo scaffolded view setting the render attribute on the parameter to false.</em></p> <p>As spring-mvc creates a new instance of the object rather than updating the existing object these fields are null. This means however that the object <strong>fails its validation before the control reaches the controller</strong>.</p> <p>A lot of my entities will have extra fields that are <strong>not updatable</strong> in the view so I'd like to be able to come up with a generic solution rather than continually doing the same work over and over again (violating DRY).</p> <p><strong>How can one allow validation to occur in a consistent manner if fields are omitted from the view?</strong></p> <pre><code> @RequestMapping(method = RequestMethod.PUT, produces = "text/html") public String UserController.update(@Valid User user, BindingResult bindingResult, Model uiModel, HttpServletRequest httpServletRequest) { if (bindingResult.hasErrors()) { populateEditForm(uiModel, user); return "admin/users/update"; } uiModel.asMap().clear(); user.merge(); return "redirect:/admin/users/" + encodeUrlPathSegment(user.getId().toString(), httpServletRequest); } </code></pre> <hr> <p><strong>Possible Solutions:</strong></p> <h2>Omit @Valid annotation from the controller.</h2> <p><strong>Pros</strong></p> <ul> <li>Easy to implement.</li> <li>Easy to understand.</li> </ul> <p><strong>Cons</strong></p> <ul> <li>Means changing the controller method for every update on every object.</li> <li>Validation is not occuring in the same place as all of the rest of the application.</li> <li>No easy way to return the binding errors back to the view (need to validate the object afterwards)</li> </ul> <h2>Add Custom Validator for methods that need omitted fields</h2> <p><strong>Example:</strong></p> <pre><code>@InitBinder public void initBinder(WebDataBinder binder, HttpServletRequest request) { if (request.getMethod().equals("PUT")) { binder.setDisallowedFields("registrationDate", "password"); Validator validator = binder.getValidator(); Validator userUpdateValidator = new UserUpdateValidator(); binder.setValidator(userUpdateValidator); } } </code></pre> <p><strong>Pros</strong></p> <ul> <li>Clear flow.</li> </ul> <p><strong>Cons</strong></p> <ul> <li>Suffers wildly from DRY problems. This means that If the domain object is altered in any way I need to revalidate. </li> <li>Field validation is not the same as Hibernate validation when saving.</li> <li>No tangible benefits over omitting validation and manually validating. </li> </ul> <p><strong>Would consider if?</strong></p> <ul> <li>Custom validator could delegate to standard JSR-303 validator but just omit fields.</li> </ul> <h2>Remove JSR-303 annotations from the domain object</h2> <p><strong>Not an option</strong> this means that there is no validation on an object before saving. Worse I believe it will affect the DDL that is producted for database, removing constraints from the DB itself. <strong>Only put in here for completeness sake</strong></p> <h2>Lookup domain object before validation occurs</h2> <p>The idea of this solution is to lookup the existing domain object before updating. Copying any not null fields to the old object from the request. <strong>Pros</strong> - The validation can go through the normal cycle. - The validation doesn't need to change depending on what method you are implying.</p> <p><strong>Cons</strong></p> <ul> <li>Database access before hitting the controller has a bit of a <strong>smell</strong>.</li> <li>I can't see any way to implement this.</li> <li>Won't work for fields that need to be omitted during other stages of the object lifecycle. For example if adding a timestamp during creation.</li> </ul> <hr> <p>I would like to know how to implement either a validator that delegates to the standard JSR-303 validator or alternatively how to lookup the object before modifying it. Or if anyone has any other possible solutions?</p> <p>Either of these solutions allow for the treatment to be consistent over multiple objects.</p> <p>Hopefully either would allow for added annotations such as. @RooCreateOnly which means the domain object could be annotated as such leaving all the validation definitions in the one place.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USWes
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. PORead only fields in spring-roo or spring-web-mvc
      1. This table or related slice is empty.
      1. VTUpMod
    1. COHave you tried hiding the fields in the UI (probably using CSS) or having these fields as hidden fields? =)
      singulars
      1. PORead only fields in spring-roo or spring-web-mvc
      1. USbhagyas
    2. COThat would work but it would mean that I need to expose properties to the client that are non of thier business (such as the hashed password)
      singulars
      1. PORead only fields in spring-roo or spring-web-mvc
      1. USWes
    3. COFor passwords, you have have no other option but to look it up from the database at the time of update. =)
      singulars
      1. PORead only fields in spring-roo or spring-web-mvc
      1. USbhagyas
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload