I would just second Jonathan's dissatisfaction with RequestFactory. As someone who has implemented an app with it, I decided I never wanted to touch it again. There is just way to much overhead and awkwardness in trying to develop a solution. Jonathan - I still think using the FetchMode on the JPA annotation isn't the right way to go. There could be other reasons why a developer uses the FetchMode (I know it is really just a guide, but still...) Why not rely on the Join statements in the query to determine what gets synced across the wire? [http://www.blinco.com/images/facebook.gif]<http://www.hs.facebook.com/... ________________________________ From: errai-dev-bounces(a)lists.jboss.org [errai-dev-bounces(a)lists.jboss.org] On Behalf Of Jonathan Fuerth [jfuerth(a)redhat.com] Sent: Monday, April 29, 2013 12:56 PM To: errai-dev List Subject: Re: [errai-dev] Errai vs. RequestFactory - where to go? Hi Thomas, I'm working toward implementing much of the functionality you've described in this branch: https://github.com/jfuerth/errai/tree/data-sync I haven't merged it into the upstream master branch yet because I've been using the To-do List demo as my working proof-of-concept, and I didn't want to break this demo on master. My plan does not include the EntityProxy feature. Instead, I'm focusing on making JPA 2.0 entities work well on the client, and allowing them automatically to sync changes between client and server. I understand that EntityProxy is one way to deal with cases where you only want a subset of an entity's properties available on the client, but in my opinion, the costs are too high: you have to write the additional proxy interface, you have to keep it in sync by hand, and maintenance coders have to deal with the existence of these types (increased cognitive load). I think these requirements violate all three Errai design mantras of "declarative rocks," "write it once," and "boilerplate sucks." We don't yet have a solution to this "subset of entity properties on the client" problem, but a more Errai-like solution would be to annotate entity properties with something that Errai respects but a JPA persistence provider ignores: maybe @ServerOnly or perhaps @ErraiTransient. A separate but related problem is knowing which related entities to populate and send to the client. My current plan (not yet tested or proven) is to use the JPQL fetch clause: any related entity designated with a fetch mode of lazy would be ignored with syncing with the client. We should know relatively soon if this is a good idea. :) I'd be happy to answer questions and/or describe my data sync plans in more detail. Once the basic "cold sync" scenario I'm working on now in the To-do List is stable and tested, I plan to write a blog post about it and post a live demo on OpenShift. The jfuerth/data-sync branch is probably 80% of the way toward that goal at the moment. -Jonathan On 2013-04-28, at 1:51 PM, Thomas Frühbeck wrote: Hi, I have been working on a CRUD-enabling plugin for Forge some time ago and have been immersed in a real world project using it's outcome for some time (Jonathan Fuerth has been discussing it already). While trying to find a useful abstraction for the persistence bridging code I totally overlooked GWT RequestFactory, which seems to provide an interesting framework for CRUD applications. IMHO the most important points: - an EntityProxy interface and along with it an EntityProxyId - client side RequestContext for instantiation and lookup - an extensible server side instantiation and lookup framework - a transportable/queuable abstraction for entity changes These are IMHO indispensable to bridge to ORM because GWT imposes too many restrictions on the classes/code it can handle. I have had an intensive look at the code to find a reason for Errai _not_ to support this part of GWT, and I think that Errai is nearly there. - Interfaces: ObjectBuilder and ClassBuilderTest show, that an implementation of new <Interface>() {} is prepared already to great extent - server side lookup: would be implementable as kind of server side "second pass" DefinitionsFactory.loadCustomMappings - I did it by hooking statically into custom MappingDefinitions It is yet unclear for me how a client side RequestContext could look like, if it should work transparent and annotation driven. Ditto for EntityChange events. I read in a blog comment by Mike Brock, that you do not plan to support RequestFactory. Can you please provide some insight why you do not want to go that route and what kind of alternative you are working on? Best regards, Thomas _______________________________________________ errai-dev mailing list errai-dev@lists.jboss.org<mailto:errai-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/errai-dev

That is actually what I was thinking actually. If I understand correctly, this would allow you to do a join (without fetch) to get the bean without the ability to 'edit it'. For example, if you had an entity: class User { Country country; } you might want to join to grab the country, but you wouldn't want to allow any changes to the fields of the country. [http://www.blinco.com/images/facebook.gif]<http://www.hs.facebook.com/... ________________________________ From: errai-dev-bounces(a)lists.jboss.org [errai-dev-bounces(a)lists.jboss.org] On Behalf Of Jonathan Fuerth [jfuerth(a)redhat.com] Sent: Monday, April 29, 2013 4:08 PM To: errai-dev List Subject: Re: [errai-dev] Errai vs. RequestFactory - where to go? I agree declaring fetch=FetchType.LAZY on a relation just for the purposes of data sync is undesirable. Indeed, you might need to use this for other purposes. But I'm suggesting we use the fetch clause in the query, like this: @NamedQueries({ @NamedQuery(name="listWithItems", query="SELECT DISTINCT tl FROM TodoList tl JOIN FETCH tl.entries WHERE tl.id = :listId") @NamedQuery(name="list", query="SELECT tl FROM TodoList tl WHERE tl.id = :listId") }) @Entity public class TodoList { @Id @GeneratedValue private long id; @OneToMany private List<TodoItem> items = new ArrayList<TodoItem>; // getters and setters } For purposes of data sync, if you want to sync TodoList 57 with all its items, you would tell Errai that the "syncable data set" you want to sync is "listWithItems" where listId=57. If you instead chose to sync based on the "list" query with listId=57, the sync would disregard the items because they're not part of the eager fetch set for that query. -Jonathan On 2013-04-29, at 3:44 PM, Joshua Blinick wrote: I would just second Jonathan's dissatisfaction with RequestFactory. As someone who has implemented an app with it, I decided I never wanted to touch it again. There is just way to much overhead and awkwardness in trying to develop a solution. Jonathan - I still think using the FetchMode on the JPA annotation isn't the right way to go. There could be other reasons why a developer uses the FetchMode (I know it is really just a guide, but still...) Why not rely on the Join statements in the query to determine what gets synced across the wire? [http://www.blinco.com/images/facebook.gif]<http://www.hs.facebook.com/... ________________________________ From: errai-dev-bounces@lists.jboss.org<mailto:errai-dev-bounces@lists.jboss.org> [errai-dev-bounces(a)lists.jboss.org] On Behalf Of Jonathan Fuerth [jfuerth(a)redhat.com] Sent: Monday, April 29, 2013 12:56 PM To: errai-dev List Subject: Re: [errai-dev] Errai vs. RequestFactory - where to go? Hi Thomas, I'm working toward implementing much of the functionality you've described in this branch: https://github.com/jfuerth/errai/tree/data-sync I haven't merged it into the upstream master branch yet because I've been using the To-do List demo as my working proof-of-concept, and I didn't want to break this demo on master. My plan does not include the EntityProxy feature. Instead, I'm focusing on making JPA 2.0 entities work well on the client, and allowing them automatically to sync changes between client and server. I understand that EntityProxy is one way to deal with cases where you only want a subset of an entity's properties available on the client, but in my opinion, the costs are too high: you have to write the additional proxy interface, you have to keep it in sync by hand, and maintenance coders have to deal with the existence of these types (increased cognitive load). I think these requirements violate all three Errai design mantras of "declarative rocks," "write it once," and "boilerplate sucks." We don't yet have a solution to this "subset of entity properties on the client" problem, but a more Errai-like solution would be to annotate entity properties with something that Errai respects but a JPA persistence provider ignores: maybe @ServerOnly or perhaps @ErraiTransient. A separate but related problem is knowing which related entities to populate and send to the client. My current plan (not yet tested or proven) is to use the JPQL fetch clause: any related entity designated with a fetch mode of lazy would be ignored with syncing with the client. We should know relatively soon if this is a good idea. :) I'd be happy to answer questions and/or describe my data sync plans in more detail. Once the basic "cold sync" scenario I'm working on now in the To-do List is stable and tested, I plan to write a blog post about it and post a live demo on OpenShift. The jfuerth/data-sync branch is probably 80% of the way toward that goal at the moment. -Jonathan On 2013-04-28, at 1:51 PM, Thomas Frühbeck wrote: Hi, I have been working on a CRUD-enabling plugin for Forge some time ago and have been immersed in a real world project using it's outcome for some time (Jonathan Fuerth has been discussing it already). While trying to find a useful abstraction for the persistence bridging code I totally overlooked GWT RequestFactory, which seems to provide an interesting framework for CRUD applications. IMHO the most important points: - an EntityProxy interface and along with it an EntityProxyId - client side RequestContext for instantiation and lookup - an extensible server side instantiation and lookup framework - a transportable/queuable abstraction for entity changes These are IMHO indispensable to bridge to ORM because GWT imposes too many restrictions on the classes/code it can handle. I have had an intensive look at the code to find a reason for Errai _not_ to support this part of GWT, and I think that Errai is nearly there. - Interfaces: ObjectBuilder and ClassBuilderTest show, that an implementation of new <Interface>() {} is prepared already to great extent - server side lookup: would be implementable as kind of server side "second pass" DefinitionsFactory.loadCustomMappings - I did it by hooking statically into custom MappingDefinitions It is yet unclear for me how a client side RequestContext could look like, if it should work transparent and annotation driven. Ditto for EntityChange events. I read in a blog comment by Mike Brock, that you do not plan to support RequestFactory. Can you please provide some insight why you do not want to go that route and what kind of alternative you are working on? Best regards, Thomas _______________________________________________ errai-dev mailing list errai-dev@lists.jboss.org<mailto:errai-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/errai-dev _______________________________________________ errai-dev mailing list errai-dev@lists.jboss.org<mailto:errai-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/errai-dev