[forge-dev] angular scaffold: parent/child relationship issues

[Vineet Reynolds Pereira]

Hi Thomas,

   I've just started working on the AngularJS scaffold. But before that, I'd have to complete a test harness that could be used in the addon tests.

   About the cyclic and bi-di issues, we've attempted to resolve that via a mapping layer, instead of relying on @JsonIdentityInfo, @JsonManagedReference, @JsonBackReference, @XMLID, @XMLIDREF or similar such annotations.

   I recommend the mapping layer, because you can flatten/de-normalize relationships at the mapping layer in a manner you desire. What I've found from using most of these annotations is that while they resolve the serialization problem, they're not very useful to clients. Some like @JSONIdentityInfo require more work to be done in the client-side because clients simply do not understand the 'non-standardized' object referencing scheme invented by Jackson.

   In Forge, to create a REST resource that employs a mapping layer, use the DTO based REST resource generator, like so (in Forge 2):

   [demo]$ rest-generate-endpoints-from-entities --generator ROOT_AND_NESTED_DTO ...

   The generated layer is a bit crude at the moment - in the future we hope to have the mapping layer depend on a separate persistence layer.

   This isn't to say that you must not use such annotations. It just so happens that if you want to expose JPA entities as REST resources, handling relationships and proxied attributes like collections is not easy. You could use the annotations to construct the REST resource, but there are chances that you might not obey certain rules in REST like allowing modifications to the REST resources using a single representation. You may have to construct multiple resource representations for the same JPA entity - one for GET (so clients can obtain the JPA entity) and another for PUT/PATCH (to modify the JPA entity and/or it's relationships). If it so happens that using annotations is more pragmatic, then by all means use it. But if your concerns include the need to have consistent resource representations for JPA entities that also allow modifications to the entities via the same representation, then a mapping layer is probably the best option.

   You can find notes on them, in the links listed below. Feel free to fire any more queries.
   1. https://gist.github.com/VineetReynolds/5108580
   2. https://gist.github.com/VineetReynolds/5524706

Vineet


----- Original Message -----
> From: "Thomas Frühbeck" <fruehbeck at aon.at>
> To: "forge-dev List" <forge-dev at lists.jboss.org>
> Sent: Monday, February 10, 2014 5:58:44 AM
> Subject: [forge-dev] angular scaffold: parent/child relationship issues
> 
> Hi,
> I wanted to work with AngularJS scaffold in Forge and ask for your help.
> 
> With Forge2, I did not find the way to install the angularjs-scaffold-x
> as addon/plugin.
> Is there some guidance available on how to use oldstyle plugins as addons?
> 
> Stepping back to Forge 1.4 I successfully created a simple parent/child
> application.
> On deployment on Wildfly 8.0.0 CR1 I found following issues:
> 
> Setup: I created a parent and then a child, the child referencing the
> parent.
> 
> Issue 1:
>   - w/o any modifications I got a StackOverflowError in
> org.codehaus.jackson.map.ser.BeanSerializer because infinite loop
> between parent/child
> 
> My solution was to:
>     - import org.codehaus.jackson/jackson-jaxrs maven dependency
> (because this is, what Wildfly seems to use per default)
>     - add @JsonManagedReference/@JsonBackReference on the
> parent.children and child.parent properties resp.
> 
> Is there some simpler/more obvious fix for the problem?
> 
> In Fasterxml Jackson 2.x there is a @JsonIdentityInfo, could this be a
> way to solve the issue?
> I seem to be unable to activate Fasterxml.Jackson on Wildfly :-/
> 
> Issue 2:
>   - by above @JsonBackReference the child.parent property was not
> serialized and so the reference did not show up as selected in the
> parents <select> options
> 
> My solution was to rewrite the EditChildController to check for
> parent.id from the parents side (because child.parent is empty):
> 
>                      for (var idx=0; idx < item.children.length; idx++) {
>                          if (item.children[idx].id === $scope.child.id) {
>                              $scope.parentSelection = labelObject;
>                              $scope.child.parent = wrappedObject;
>                          }
>                      }
> 
> Original code:
>                      if($scope.child.parent && item.id ==
> $scope.child.parent.id) {
>                          $scope.parentSelection = labelObject;
>                          $scope.child.parent = wrappedObject;
>                          self.original.parent = $scope.child.parent;
>                      }
> 
> Again I ask for your expertise, if this is a problem I introduced by
> misusing @JsonBackReference or if this needs a fix in the scaffold.
> 
> Thank you for your great work on Forge and this incredible AngularJS
> plugin :-)
> 
> Thomas
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>