Another argument: what would EntityManager#merge(entity) be for if the entities would not be mutable?
LieGrue, strub >________________________________ > From: Mark Struberg <[email protected]> >To: "[email protected]" <[email protected]> >Sent: Sunday, 20 October 2013, 13:51 >Subject: Re: Entity cant be refreshed with new list values > > >Romain, that's nowhere in the spec. Thus it must work. Really! > >The only thing which is specified to be immutable are lists returned by >query.getResultList. >That's the reason why you should not back a sortable h:dataTable by a list you >get from JPA directly. >All other stuff is perfectly mutable. > >LieGrue, >strub > > > > >>________________________________ > >> From: Romain Manni-Bucau <[email protected]> >>To: [email protected] >>Sent: Sunday, 20 October 2013, 10:00 >>Subject: Re: Entity cant be refreshed with new list values >> >> >>Not really. An entity handles a state which can prevent it. Nothing >>mandates it to work >> >>Le 20 oct. 2013 09:50, "José Luis Cetina" <[email protected]> a écrit : >> >>> What about using a detached entity?? The detached entity will work like a >>> DTO? >>> >>> From Real World Java EE Patterns (Adam Biem) 2009 >>> Problem >>> The origin problem statement was: “You want to transfer multiple data >>> elements over a tier” >>> ( >>> >>> http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html >>> ). >>> This particular problem was elegantly solved in Java EE 5 with detachment >>> of persistent entities. There is >>> no need for the introduction of another class just for transferring the >>> entities data. JPA entities can >>> implement a java.io.Serializable interface and be transferred between >>> tiers, even remote ones. >>> CMP 2.x entities weren’t Serializable, the developer was forced to copy >>> their states to a remotely >>> transferable structure—the Transfer Object. >>> >>> >>> >>> 2013/10/19 Howard W. Smith, Jr. <[email protected]> >>> >>> > responses below... >>> > >>> > On Sat, Oct 19, 2013 at 3:46 PM, Mark Struberg <[email protected]> >>> wrote: >>> > >>> > > be careful with immediate=true. You get all sorts of nasty side >>> effects. >>> > > >>> > > see page 92 in >>> > > >>> > >>> http://people.apache.org/~struberg/eesummit2013/Java%20EE%20Summit%20-%20pitfalls%20in%20EE.pdf >>> > > >>> > > >>> > I definitely agree and understand about immediate=true, and guess what, i >>> > found it very useful to disable validation as instructed on page 92 of >>> the >>> > PDF file. >>> > >>> > clarification of my use/understanding: >>> > >>> > i am 'not' using immediate=true, when i user is to select a row on >>> > datatable, and then click commandbutton/link/menuitem, which does a POST >>> of >>> > the selected row on the datatable, and bean uses the selected row to >>> > prepare the UI for the next view that is 'rendered' via >>> > ui:include=#{bean.page}. see below and keep reading, please. >>> > >>> > <p:menuitem value="Add" icon="ui-icon ui-icon-circle-plus" >>> > >>> > actionListener="#{pf_pointOfContactController.prepareCreate()}" >>> > update="#{pf_pointOfContactController.getAjaxUpdate()}"/> >>> > <p:menuitem value="Edit" icon="ui-icon ui-icon-pencil" >>> > >>> > actionListener="#{pf_pointOfContactController.prepareEdit()}" >>> > update="#{pf_pointOfContactController.getAjaxUpdate()}"/> >>> > <p:menuitem value="View" icon="ui-icon-folder-open" >>> > >>> > actionListener="#{pf_pointOfContactController.prepareView()}" >>> > update="#{pf_pointOfContactController.getAjaxUpdate()}"/> >>> > <p:separator/> >>> > <p:menuitem value="Copy to Ordered By" icon="ui-icon ui-icon-newwin" >>> > >>> > actionListener="#{pf_pointOfContactController.copySelectedRows()}" >>> > update="#{pf_pointOfContactController.getAjaxUpdate()}"/> >>> > <p:menuitem value="Delete" icon="ui-icon ui-icon-trash" >>> > >>> > >>> actionListener="#{pf_pointOfContactController.confirmDeleteSelectedRows()}" >>> > update="#{pf_pointOfContactController.getAjaxUpdate()}"/> >>> > >>> > but, for a readonly page that has commandbutton/links to render a new >>> view, >>> > based on the current @Entity that is held in the JSF controller/bean >>> class, >>> > i use immediate=true without issue and I think it fits/meets the >>> > occasion/requirement, because there is no need to do validation phase or >>> > update model values. see below. :) >>> > >>> > <p:commandButton value="Browse" icon="ui-icon-search" >>> immediate="true" >>> > update="#{pf_pointOfContactController.getAjaxUpdate()}" >>> > >>> > actionListener="#{pf_pointOfContactController.prepareList()}"/> >>> > <p:commandButton value="Delete" icon="ui-icon ui-icon-trash" >>> > immediate="true" update="#{pf_pointOfContactController.getAjaxUpdate()}" >>> > >>> > actionListener="#{pf_pointOfContactController.confirmDelete()}"/> >>> > <p:commandButton value="Edit" icon="ui-icon ui-icon-pencil" >>> > immediate="true" update="#{pf_pointOfContactController.getAjaxUpdate()}" >>> > >>> > actionListener="#{pf_pointOfContactController.prepareEdit()}"/> >>> > >>> >>> >>> >>> -- >>> ------------------------------------------------------------------- >>> *SCJA. José Luis Cetina* >>> ------------------------------------------------------------------- >>> >> >> > >
