tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Entity cant be refreshed with new list values
Date Sun, 20 Oct 2013 19:21:35 GMT
Openjpa clearly doesnt support today...and no Mark it can or not work by
spec...
Le 20 oct. 2013 18:04, "José Luis Cetina" <maxtorzito@gmail.com> a écrit :

> Responses inline.
>
> El 20/10/2013 06:51, "Mark Struberg" <struberg@yahoo.de> escribió:
> >
> > Romain, that's nowhere in the spec. Thus it must work. Really!
>
> If this is true, what im doing wrong? Or this is openjpa or tomee issue?
>
> >
> > 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 <rmannibucau@gmail.com>
> > >To: users@tomee.apache.org
> > >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" <maxtorzito@gmail.com> 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. <smithh032772@gmail.com>
> > >>
> > >> > responses below...
> > >> >
> > >> > On Sat, Oct 19, 2013 at 3:46 PM, Mark Struberg <struberg@yahoo.de>
> > >> 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*
> > >> -------------------------------------------------------------------
> > >>
> > >
> > >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message