You're right too ;-) I didn't want to substitute to the plugin documentation. I'd prefer the "include properties" behaviour anyway.
I believe a good idea could be to use @JsonInclude annotation on the entity properties to define (just ONE time on the entities) which of their properties are "safe to return" in the json serialization Thank You again. On Mon, Jul 13, 2009 at 9:33 AM, Nils-Helge Garli Hegvik<nil...@gmail.com> wrote: > Did you look at the "Excluding properties" example in the json plugin > documentation? > > Nils-H > > On Mon, Jul 13, 2009 at 9:15 AM, GF<gan...@gmail.com> wrote: >> You're absolutely right, >> but there is a "security reason", in real-world application, the >> objects i get from business service, are usually JPA entities, and >> putting a "full JPA entity" on the json result will lead to issues in >> the case there are some properties of that object that have to kept >> "hidden" to the end users.. (i.e. in the case of a "User" entity, >> would a not good idea to return in the json result its hashed >> password). >> >> Your suggestion would surely lead to a "clean code" but an >> unexperienced programmer might show to its website user some >> information he didn't want to... >> >> >> >> >>> A quick look at your tutorial makes me think you are underestimating the >>> capability of the JSON plugin. It is fully capable of serializing most java >>> objects to JSON. Rather than explicitly creating a hashmap, why not put the >>> 'item' on the action and then set a json result with item configured as the >>> root object. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> For additional commands, e-mail: user-h...@struts.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
