Ok seems this is justabout how JSF works. I found another interessing discusssion and thought it would fit in here just in case others experience similar problems:
http://forum.java.sun.com/thread.jspa?threadID=5116147 --Martin Andrew Robinson-5 wrote: > > It *should* hit the database twice, unless you use a > conversation-scoped bean (see sandbox, or seam for this type of > scope). > > The components have to access their model data during decode so they > can properly iterate over the data and decode any actions from the > client. For data tables, they are iterated over for every lifecycle > phase. If the table never did this, you would never have any actions > or updates to components inside tables, iterators, trees, etc. > > If you need the data to stick around, and is serializable, use the > t:saveState component. This way the data is not reloaded for your > decode/validate/update phases. You would then reload the data after > your action changes something > > -Andrew > > On 10/22/07, Martin Ahrer <[EMAIL PROTECTED]> wrote: >> >> The seam factory annotation still won't do it - it only takes care that >> data >> is prepared only once when it is requested first time (See also >> http://www.ibm.com/developerworks/web/library/j-seam1/index.html Factory >> components). >> >> In the case that I have described, JSF would request data for the table >> the >> first time in the APPLY_REQUEST_VALUES phase - BUT it (here it would be >> your >> createModel() method) can't retrieve the right data as the query criteria >> form values have not yet been transferred to the backing bean it is bound >> to! >> Next JSF would request data during the RENDER_REPONSE phase. NOW the >> right >> data can be retrieved using the criteria properties that have been >> applied >> in the UPDATE_MODEL_VALUES phase. >> >> So JSF forced me to hit the database twice, BUT skipping the first >> database >> by only allowing database access during the RENDER_RESPONSE phase causes >> the >> table component not to work properly (can't click a row ... I have tried >> this with the dataTable tag from JSF core as well) >> >> --Thanks Martin >> >> >> >> Andrew Robinson-5 wrote: >> > >> > Seam's injection with factory support would work for you I would >> believe. >> > >> > <tr:dataTable value="#{mymodel}" ...> >> > >> > @Name("doesntMatter") >> > public class Whatever { >> > >> > @In(required=false) @Out(required=false) >> > private DataModel mymodel; >> > >> > @Factory("mymodel") >> > public DataModel createModel() { >> > ... load the model here >> > } >> > // for programmatic access: >> > public DataModel getDataModel() { >> > if (mymodel == null) { >> > mymodel = createModel(); >> > } >> > return mymodel; >> > } >> > } >> > >> > This would force #{mymodel} to be lazy loaded as needed and backing >> > beans could use "getDataModel" >> > >> > You could then also have a on-load function to load this data too if >> you >> > want. >> > >> > -Andrew >> > >> > >> > On 10/20/07, Martin Ahrer <[EMAIL PROTECTED]> wrote: >> >> >> >> I'm already using request scope to keep the managed bean qbeController >> >> (this >> >> is the one providing the DataModel) so that data is refreshed every >> time >> >> the >> >> page is refreshed. >> >> >> >> With using the JSF 1.2 <f:view> beforePhase and afterPhase method >> >> bindings >> >> I already try to load data at a very specific phase. I know about >> >> jsf-comp, >> >> shale (does not work with JSF 1.2) and seam, this is almost the same >> >> solution just different tags or annotations to control the phase and >> when >> >> to >> >> invoke a specific method. I don't think they would do the trick here! >> >> Correct me if I should be wrong! >> >> >> >> May be I did not state it clearly enough, the problems that I'm >> fighting >> >> are >> >> a result from restricting data loading to a specific phase. Especially >> >> delaying data loading to before RENDER_RESPONSE causes the Trinidad >> table >> >> not to allow me to click a row and perform a selection method. It >> simply >> >> would not create a request! I don't know if this is a Trinidad problem >> or >> >> if >> >> this is a general issue that results from the JSF life-cycle. As I >> move >> >> data >> >> loading to the earlier APPLY_REQUEST_VALUES phase the Trinidad table >> >> works >> >> BUT data loading can't be performed properly because the backing bean >> has >> >> not yet been refreshed with the query criteria form input :( >> >> >> >> >> >> >> >> Andrew Robinson-5 wrote: >> >> > >> >> > Typically, what I have seen is to store the data in a request scoped >> >> > member variable. This is used with "if not loaded, load, otherwise >> use >> >> > current instance" paradigm. >> >> > >> >> > There are 3 libraries that I am aware of that also provide on-load >> >> > functionality, so that you can load the data before rendering (thus >> >> > making error handling easier): >> >> > >> >> > * jsf-comp on-load >> >> > * Seam >> >> > * Shale >> >> > >> >> > The simplest way is to store you model directly on the request >> context >> >> > from the external request. >> >> > >> >> > -Andrew >> >> > >> >> > >> >> > >> >> >> >> -- >> >> View this message in context: >> >> >> http://www.nabble.com/-trinidad--what-is-the-proper-lifecycle-phase-for-populating-a-%3Ctr%3Atable%3E-tf4654950.html#a13308254 >> >> Sent from the MyFaces - Users mailing list archive at Nabble.com. >> >> >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/-trinidad--what-is-the-proper-lifecycle-phase-for-populating-a-%3Ctr%3Atable%3E-tf4654950.html#a13339401 >> Sent from the MyFaces - Users mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/-trinidad--what-is-the-proper-lifecycle-phase-for-populating-a-%3Ctr%3Atable%3E-tf4654950.html#a13370588 Sent from the MyFaces - Users mailing list archive at Nabble.com.
