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

Hi Max, I guess should have replied back to the ML with details of the discussion we had in #forge. We might introduce support for scaffolding immutable entities correctly. That is however a lower priority item, since we anticipate fewer object models to use immutable types. And the extra effort needed to support these types kind of warrant a lower priority for this item. For now, this is being tracked in FORGE-978 <https://issues.jboss.org/browse/FORGE-978>;. I havent thought about using a Map based approach for the search criterias, but thats probably because I didn't consider it at all. I was considering the creation of new mutable types that mirror the immutable ones, but if the Map based approach works for both search criteria facelet as well as for the edit entity facelet, I'll go for it. As long as the generated scaffold is not very far off from how end-users model their apps for production, I'll use any possible solution.

Thanks, Vineet ----- Original Message ----- > From: "Max Rydahl Andersen" <manderse(a)redhat.com&gt; > To: "forge-dev List" <forge-dev(a)lists.jboss.org&gt; > Sent: Thursday, June 27, 2013 3:27:21 PM > Subject: Re: [forge-dev] Scaffolding immutable JPA entities > > 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 > &gt;forge-dev(a)lists.jboss.org > >https://lists.jboss.org/mailman/listinfo/forge-dev > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

> > You would be generating like a <Entity>DO instead ? I didnt quite catch that. To clarify, it would be a POJO/DTO; certainly not an Entity since I'd like to avoid issues with the EntityManager deciding to persist or manage it.

> > > >Thanks, > >Vineet > > > > > > > >----- Original Message ----- > >> From: "Max Rydahl Andersen" <manderse(a)redhat.com&gt; > >> To: "forge-dev List" <forge-dev(a)lists.jboss.org&gt; > >> Sent: Thursday, June 27, 2013 3:27:21 PM > >> Subject: Re: [forge-dev] Scaffolding immutable JPA entities > >> > >> 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 > >> &gt;forge-dev(a)lists.jboss.org > >> >https://lists.jboss.org/mailman/listinfo/forge-dev > >> _______________________________________________ > >> forge-dev mailing list > >> forge-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/forge-dev > >> > >_______________________________________________ > >forge-dev mailing list > &gt;forge-dev(a)lists.jboss.org > >https://lists.jboss.org/mailman/listinfo/forge-dev > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev