HTML5 local object persistence for GWT

117 views
Skip to first unread message

joergviola

unread,
Aug 29, 2011, 12:24:58 PM8/29/11
to google-we...@googlegroups.com
Hello,
I want to announce a new lib for HTML5 gwt apps:


Using it, you can directly persist objects to local HTML5 storage or database, whatever is available.
Moreover, synchronisation to a server is possible, currently to GAE using objectify.

GWT generators are used to generate class descriptors for the persistent classes.
At runtime, these descriptors are used to create JSON for storage or an SQL for database persistence.

The persistence model currently is quite simple and modelled after the objectify API.

I would be happy if someone just could check the concept and tell whether this lib would be useful.

Thanks a lot, Joerg

J.Ganesan

unread,
Aug 30, 2011, 8:15:55 AM8/30/11
to Google Web Toolkit
Congratulations. The simplicity is striking. This library really gives
an object orientation tinge to persistence. I believe this library is
a natural extension to GWT programming model.
It is useful for those projects not demanding a deep object graph. Of
course, when this library is extended to take care of
java.util.Collections and of circular references, it will be lot more
useful.

J.Ganesan
www.DataStoreGwt.com

joergviola

unread,
Aug 30, 2011, 8:36:35 AM8/30/11
to Google Web Toolkit
Thank you for this review.
Indeed, the coverage of usually used object reference semantics is
crucial.
On the other hand, this is a long way to go...
Consider for example the complex semantics to eager and lazy loading
of references.

My direction would be:
Try allowing List and arrays as to-many field types.
Follow objectify in that Keys as values mean lazy loading (which then
has to be done manually).
Try allowing real references, but only with eager semantics - then
taking properly care of circular references.

Alain Ekambi

unread,
Aug 30, 2011, 11:23:43 AM8/30/11
to google-we...@googlegroups.com
Really impressive work.
Well done pal :)

2011/8/30 joergviola <joerg...@googlemail.com>
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.




--


Harald Pehl

unread,
Aug 30, 2011, 12:29:16 PM8/30/11
to google-we...@googlegroups.com
Well doe Joerg! The API is straightforward but very powerful.

I noticed in JSONEntityWriter and JSONEntityReader you (de)serialize the entites using the GWT JSON API. I'm the author of Piriti a JSON / XML mapper for GWT: http://code.google.com/p/piriti/. Piriti is able to (de)serialize whole object graphs from/to JSON. References, collections, arrays, primitive and basic data types are supported (see http://code.google.com/p/piriti/wiki/SupportedTypes for a full list).

Maybe we can join forces and add something like a PiritiEntityWriter / PiritiEntityReader? What do you think?

- Harald

joergviola

unread,
Aug 31, 2011, 4:25:36 AM8/31/11
to google-we...@googlegroups.com
Thanks Harald

Hey - Piriti is nice - if I only knew about it some months earlier, when I had to write a JSON-based API to a GWT App...
How does it compare to AutoBeans?

As of using Piriti for local storage: Each object instance in a graph has to be stored individually in the storage. So we would need some means of hooking into to piriti graph traversal to store the instance, right?

If that would be possible, use of pirity could make the job ob persisting whole graphs a lot easier.

Harald Pehl

unread,
Aug 31, 2011, 5:20:17 AM8/31/11
to google-we...@googlegroups.com
I started Piriti as an XML mapper for GWT back in January 2010. JSON mapping was introduced some months later. So it has no relation to AutoBeans. It's just an alternative way to (de)serialize POJOs. Although the output is very similar, Piriti is not based on marker interfaces, but real POJOs. See also http://code.google.com/p/piriti/wiki/Comparison for a comparison with other mappers.

The idea off hooking into graph traversal is an interesting concept. I would suggest events and handlers to get notified when a model / property is written to JSON resp. read from JSON:

public interface JsonWriter<T> {
   ...
   HandlerRegistration addWriteModelHandler(WriteModelHandler<T> handler);
   HandlerRegistration addWritePropertyHandler(WritePropertyHandler<?> handler);
   ...
}

public interface WriteModelHandler<T> extends EventHandler {
   void onBeforeWriteModel(WriteModelEvent<T> event);
   void onAfterWriteModel(WriteModelEvent<T> event);
}

public interface WritePropertyHandler<T> extends EventHandler {
   void onBeforeWriteProperty(WritePropertyEvent<T> event);
   void onAfterWriteProperty(WritePropertyEvent<T> event);
   void onSkipProperty(WritePropertyEvent<T> event);

joergviola

unread,
Sep 7, 2011, 3:05:50 PM9/7/11
to Google Web Toolkit
Hi,

just a remark: You can now use direct object references in your
persistent class:
class A {
long id;
B b;
}
if A and B are Persistable. b will be put and get EAGER, so beware of
performance issues!
I plan to support a Lazy Annotation that instantiates only empty
objects with the ID and can be fetched later.
Also Collections of objects will be supported.
Circular references will also be handled properly.

Please use http://groups.google.com/group/mobile-objects-discuss for
further discussions.

joergviola

unread,
Sep 7, 2011, 3:08:07 PM9/7/11
to Google Web Toolkit
Yepp, something like that would work.
I am currently working on persisting object graphs eagerly.
When I come across the local storage I will take a look at piriti
again.

Please use http://groups.google.com/group/mobile-objects-discuss for
further discussions.

On 31 Aug., 11:20, Harald Pehl <harald.p...@googlemail.com> wrote:
> I started Piriti as an XML mapper for GWT back in January 2010. JSON mapping
> was introduced some months later. So it has no relation to AutoBeans. It's
> just an alternative way to (de)serialize POJOs. Although the output is very
> similar, Piriti is not based on marker interfaces, but real POJOs. See alsohttp://code.google.com/p/piriti/wiki/Comparisonfor a comparison with other
Reply all
Reply to author
Forward
0 new messages