Feature/error objects in validation #58
Conversation
|
reyez » ninja #178 SUCCESS |
| * @param fieldViolation | ||
| */ | ||
| void addFieldViolation(FieldViolation fieldViolation); | ||
|
|
|
reyez » ninja #179 SUCCESS |
| List<ConstraintViolation> getGeneralViolations(); | ||
|
|
||
| /** | ||
| * Add a field violation to the list of filed violations. |
There was a problem hiding this comment.
The method itself is pretty much self explanatory.
|
LGTM, just one general comment on the documentation and it's more about the orientation that this project wants to take concerning documentation. Personnally I like to write self explanatory code and when I add comments, it's only to add information that the user may not understand by only reading the method name. Since this is a framework, more is better than less, but that also means that we need to maintain both the documentation and the code. I'd like to see Raphael inputs on that since it will influence the way I review that kind of subject in the future. |
|
Hi @christiangoudreau and @philipsommer, first of all thanks for the contribution :) It is really cool to see that the framework gets better step by step. And @christiangoudreau many thanks for reviewing the code. Regarding comments, code style and many other things: I think Christian's comment points into the right direction: The whole human setup of the project is not yet right. Currently I am the single point of failure. Plus - there are not many "rules" how to do things. I tend to like that (not having rules), but at some points there should be some constraints and guidelines. Regarding the actual comments I totally agree that keeping documentation in two places (method + javadoc + ...) can be problematic. But to me it is even more problematic not having a human readable documentation in addition to method names. I really like it when I can use Eclipse to hoover over a method getting a nice description showing what the method actually does (I even like it more when there is an example showing something meaningful). But I agree with @christiangoudreau that there are cases where this might not be the best way to do it... Therefore: The next big steps for ninja will be to bring more people into the boat and replace "Raphael" with something more meaningful ;) This will happen soon - and I'd really invite you both to join the party :) Cheers and many thanks again! Raphael |
Feature/error objects in validation
|
Hi Christian, hi Raphael, thank you guys for your reviews and comments. @rafael: I would like to implement a new feature to ninja in the near future. This feature should help us to unify http-error codes and what the api callee should see from the inner life of ninja (now, if an error occurs, the callee sees the exception stack trace). So, my thoughts went in the direction to implement (additional to the yet working filter-Annotation) an annotation for post-filters. Those filters should be able to catch exceptions and modify the result of the controller function. This also could be a first step to apply a simple caching mechanism. Please let me know about your thoughts. Wish you both a nice day, best, Philip Am 15.10.2012 um 12:10 schrieb reyez:
Philip Sommer | Software Developer Managing Director: Dr. Johann Kempe | Registered Office: Berlin, Germany | Registration Court: Amtsgericht Berlin Charlottenburg, HRB 141183 B |
Some enhancements in validation :-)