| « Tout Valtech à la carte… gratuitement ! | JBoss Messaging : a kind of magic… » |
Gilead: send your Hibernate entities... well... wherever you want :-)
18 months (and 15 000 downloads) have past since release '0.1' of Hibernate4GWT. It was a lot of work, testing, and thanks to feedback from the community, it seems that the library has proved its utility.
It was time to evolve, so I added Flex/BlazeDS support to the library (since Adobe framework suffers of the same issues) and two useful annotations (@ServerOnly and @ReadOnly) for a better control of the clone and merge operations.
I also renamed the project to Gilead (for Generic Light Entity Adapter) to reflect a more general purpose than just Hibernate and GWT, refactored the project (split in modules) and change of web site (god bless CMS :D )
And the future is even more exciting : thanks to Vincent Legendre, release 1.2.1 will add Comet support and a new adapter for XML. Alexandre Pretyman adds UnionCustomBeanTransformer to control object transformation, and Aymen Sayhi provides Maven support. All of them are planned for January 2009
On my side, I am working on Hibernate interface loading (to simplify object graph loading, without lazy loading and LazyInitializationException) and other JPA implementations, such as EclipseLink and OpenJPA, is still planned for mid 2009.
So, stay tuned B)
1 commentaire
as you know I am a fan of Gilead. Gilead makes development much faster because I can use the domain objects in the (GWT) client without filling the contents into DTOs or something like that.
I think it is a modern problem that hibernate instrumented instances must be serialized. In conventional webapps the values are filled into the view components on the server side so there were no need to serialize persistent objects.
Using Gilead I ran into two issues that I am not really sure how to solve:
1. proxy information. The User object I am using has got lots of collection mappings to other tables (e.g. address, buddies, invitations etc). I found out that the proxy information for a collection are about 200 Bytes (that serialized HashMap which is then Base64 encoded). So every user object has got a size of about 2kB (10 Collections x 200 Bytes). So if I want to display a user in a list on the client, much data must be loaded even if the collections are not initialized.
2. fields that must not be shown to the public: Like many applications in my app you can view the pages as guest (not logged in) and as logged in user. In many cases I want to show less information to guests than to logged in users. There are also differences if you are looking at "your" profile or at the profile page of someone else.
Of course I can setVisible(false) to a widget that must not be shown. But if you look at the data stream (i.e. with firebug) you can see all the information that is present in the database and has been mapped with hibernate for the particular User object.
I think putting more "delicate" informations into other tables that are not join-fetched is not the case for me because I need higher granularity...
example:
- Guest: show user's name.
- logged in Person: show user's name and address
- "my Profile": show user's name, address and birthday
In the "conventional" webapp I did not have this problem because the persistent objects only exist on the server side.
What are your experiences with these two issues? Do you know any patterns or best practice?
Kind Regards
Andreas
Flux de commentaires pour cet article