Re: [Trinidad] how to detect phases

[Renzo Tomaselli]

Gerhard,     good suggestion, thanks. I already use a phase listener, so I just need to add a current phase entry to the request map. Then it will be up to any bean to decide upon loading. I always wondered why FacesContext does not offer any current phase info. My business layer is a remote CORBA CMS and I must render up-to-date contents, accounting for real concurrent changes. Thus rendering needs fresh data. -- Renzo Gerhard Petracek wrote: hello renzo, ok - what you wrote about the usage of request-scoped beans is completely ok in view of: use them if it is possible (that's good practice). (however, you have to know if you really need the latest "snapshot" of your data provided by the business layer and if you need to re-/load data before rendering or not. - it's a specific fact of your application.) if i didn't miss an important detail my suggestion also works for your described scenario - some additional suggestions: just use request-scoped flags and re-/set them within a phaselistener. e.g.: choose one or more phase(s) where you would like to re-/load your data and set a flag before each "target-phase" (e.g. that loading data is allowed) and after the phase set the flag to a value which indicates that loading data isn't allowed/desired. if there is a second phase which requires updated data: also work with this logic (you can use multiple phaselisteners - or one for all phases and within the beforePhase and afterPhase methods you check for your phases you are interested in.) (use: FacesContext.getCurrentInstance().getExternalContext().getRequestMap() if you have to get the map via source code) do you have a remote business layer? if not: a second approach is (if applicable for your application): more intelligent caching within the business layer (-> in this case you don't have to adjust the view layer) regards, gerhard 2007/11/30, Renzo Tomaselli <[EMAIL PROTECTED]>: Gerhard,     since I have to account for concurrent changes of the underlying business layer, I'm afraid things are a bit more complicated. In general, getters/setters (and any listener) are the only available triggers to load data while using request-scoped beans, as I do (many request-scoped beans and one single session-scoped). E.g. the bean is recreated from scratch at each request, so that data must be reloaded or retrieved from cache or state saving. Furthermore, I can't rely - while rendering - upon having my model already prepared during a previous restore phase. These two phases have different requirement: - restoring *must* deal with the same model as saved during the previous rendering, or troubles may occur if updating fields. - rendering must reload data since the business layer might have changed in between. Thus in general - without full state saving such as in using t:saveState, I need to load data twice. However the first time is not really needed for readonly components. This is what I want to avoid by speculating on how many times a model is requested. -- Renzo Gerhard Petracek wrote: hello renzo, i would suggest: try to avoid loading data within getter methods. so the question if you can rely on such mechanisms doesn't occur. (if you really don't see a way to avoid loading data within getter methods - i would use e.g. request-scoped custom flags -> don't load data again, if the according flag exists/or contains a specific value. or for other scenarios: if it is possible and you don't reference data until you load it - check if data is already referenced or not...) however, i think there are also other approaches to solve your requirements. i just offered one (of ?) possible solution. regards, gerhard 2007/11/30, Renzo Tomaselli < [EMAIL PROTECTED]>: Hi, as many others - I'm trying to optimize loading data from my business layer, avoiding to do it as much as possible while restoring a view. Now I noticed that components needing a complex data model as their value (tree, table, etc.) ask the backing bean for this model exactly twice: one while restoring, one while rendering. This is different than normal getters which appear to be invoked a variable number of times. The question is: how safe is to speculate on this behavior to decide about current phase, and to arrange (or skip) data loading accordingly ? -- Renzo -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces