6:28 p.m.
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
12:31 a.m.
On 02/10/2014 01:28 AM, Thomas Frühbeck wrote:
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
Hey ! Vineet will certainly give you the right answer but
which
strategy option did you use to generate your REST endpoint ? You have to
make sure to use "--strategy ROOT_AND_NESTED_DTO" this way your
relations will be managed well.
i.e : "
|rest endpoint-from-entity --contentType application/json
org.jboss.aerogear.judconcricket.model.* --strategy ROOT_AND_NESTED_DTO
|
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
3:42 a.m.
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(a)aon.at>
To: "forge-dev List" <forge-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
3972
days inactive
3972
days old
2 comments
3 participants
participants (3)
-
Sebastien Blanc -
Thomas Frühbeck -
Vineet Reynolds Pereira