This is happening because you can't use the entity it self as "data entry"
model
to pass to criterias/queries etc ?
Could it make sense to have a way to fallback on to map based approach for search
criterias
which are not mapped to strongly typed classes when you are dealing with such immutable
types
(or rather entities without setters) ?
/max
On Mon, Jun 24, 2013 at 07:23:47PM -0400, Vineet Reynolds Pereira wrote:
Hey all,
FORGE-917 <
https://issues.jboss.org/browse/FORGE-917> was fixed a few days back
where in immutable classes were excluded from the generated scaffold, i.e. no
create,search,update screens were generated for such classes.
I've run into a related problem where other JPA entities are composed of one or
more immutable types. The generated scaffold does not allow creation of the constituent
immutable types (obviously) along with the root JPA entity. Additionally, if these root
JPA entities contain Bean Validation constraints on the immutable types, then creation or
updation of these entities would fail depending on what constraints are imposed.
I think this scenario demands that this limitation be documented with possible
approaches to resolve this issue. Obviously, it makes little sense to also prevent
scaffolds from being generated for JPA entities composed of immutable types. Also, this
makes revisit FORGE-917 - should we revisit the design of the generated managed
(view)beans to support immutable types?
What do you think?
Vineet
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev