Patch with @PostLoad, support for generic lists, and other fixes.

[GoogleCodeExporter]

This patch adds support for:
 - @PostLoad lifecycle method; called with JSONObject after fields are assigned
 - Date type support
 - Returning null for numeric types that are empty strings
 - No need for @Facebook(contains=Class); uses reflection to get the type
 - Support private/protected constructors

I made a lot of changes (like the logging stuff) before you did in trunk, so my 
build file changed at the same time. I didn't do much of a compare to your 
build file (I just ignored your update) for changes since I added a test target 
and had other changes; I'm pretty sure my changes are a logical superset of 
what you did.

Original issue reported on code.google.com by scotthernandez on 14 Jun 2010 at 4:10

Attachments:

• restfb-patch.txt

[GoogleCodeExporter]

Awesome - some of these I've been too lazy to get around to myself and some I 
wasn't aware could be done "easily" like parameterized-type resolution at 
runtime.

I will try to get these into trunk in the next few days...will probably make 
some small changes.  Really appreciate your sharing this.  Am happy to give you 
credit on the website in addition to the source code if you'd like me to plug 
anything of yours (not that I'm getting tons of traffic, but hey)

Original comment by mark.a.a...@gmail.com on 14 Jun 2010 at 2:33

[GoogleCodeExporter]

Original comment by mark.a.a...@gmail.com on 14 Jun 2010 at 2:33

• Added labels: Milestone-Release1.6, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Cool, I might also add "caching" of the type so there is less reflection. I 
would probably do what I did with another project but this time, keep a static 
Class cache.

This MappedClass instance is saved in a scope where it is much more efficient 
than doing it every time. It is more complicated since we support mapping 
arbitrary depths and extensions, but you get the idea.
http://morphia.googlecode.com/svn/trunk/morphia/src/main/java/com/google/code/mo
rphia/mapping/MappedClass.java

I've got a bit of experience with mapping and reflections at this point :)

Original comment by scotthernandez on 14 Jun 2010 at 3:40

[GoogleCodeExporter]

WRT the generic stuff and the type conversions, why not use Jackson as a JSON 
parser?  It handles all these issues already (including generic fields and 
superclasses).  It also provides some very clever ways of doing conversions by 
annotating the mapped class (or registering converters).

I'll start a discussion thread on the google group.

Original comment by lhori...@gmail.com on 23 Jun 2010 at 6:15

[GoogleCodeExporter]

For posterity...here's the link to the Google Group where we continued the 
discussion:

http://groups.google.com/group/restfb/browse_thread/thread/8f95ed34dd35ef95

Original comment by mark.a.a...@gmail.com on 25 Jun 2010 at 12:27

[GoogleCodeExporter]

RE: the concept of a @PostLoad annotation, is the goal there for your mapped 
classes to be immutable?  Or that you don't want to have to have an external 
class post-process them after construction?  ...or both?

Original comment by mark.a.a...@gmail.com on 26 Jun 2010 at 4:12

[GoogleCodeExporter]

I'm not sure what you mean. The @PostLoad annotation provides both a hook to 
process data after the json mapping (in your java fields), and the json data in 
case simple mappings require additional logic or transformation.

In my case I combine a few fields into an custom object, and convert some data 
types.

Original comment by scotthernandez on 26 Jun 2010 at 6:12

[GoogleCodeExporter]

Yeah, sorry, should have been more clear - was just curious more than anything 
if you were requesting because there was a funky case that was impossible to 
achieve using the current code, or if this was just a way to sidestep something 
like

User user = facebookClient.fetchObject("me", User.class);
postProcess(user);

by wrapping up the postprocessing logic inside of User instead.  When I asked 
about immutability, it was because making a mapped class immutable would make 
it more complicated for something similar to the above code snippet I posted to 
work, but having a private @PostLoad method inside of the mapped class to do 
the additional processing would make that much easier.

Anyway, don't worry about it, I do plan to include this in 1.6, although I 
might change the name from @PostLoad to something else.  Will comment here with 
an update when it's checked in.

Original comment by mark.a.a...@gmail.com on 27 Jun 2010 at 3:16

[GoogleCodeExporter]

It was impossible with the previous code.

It fits with the ability to make an immutable instance just like using a 
constructor, or (de)serialization methods, and/or this annotation; All other 
setters would fail in those cases. But that wasn't my need.

I can't use your example because the data is gone by the time I call 
postProcess(User/s).

Normally I would argue against changing the name, since it is a standard 
lifecycle event in many other frameworks (like JPA for example), but I already 
have 2 other @PostLoad annotations on some of my entities -- it is getting 
verbose with the whole package names.

Original comment by scotthernandez on 27 Jun 2010 at 3:40

[GoogleCodeExporter]

Punting @PostLoad to 1.7 or a future release - I think you guys are using 
BatchFB now so this one's not so important to you anymore :)

Original comment by mark.a.a...@gmail.com on 27 Dec 2010 at 6:16

• Added labels: Milestone-Release1.7
• Removed labels: Milestone-Release1.6