Hi, thanks!
AFAICS you already changed code. Did you also solved this issues? Maybe you could share your changes. Regards, Thomas 2012/3/14 Leonardo Uribe <[email protected]> > Hi > > In theory there exists 2 ids: the viewId without resolve, and the > logical viewId. The first one is the one extracted from request path, > and usually contains the suffix mapping (for example /home.jsf) . The > logical is the one that points to the real resouce, for example > /home.xhtml or /home.jspx or /home.xml). This is an example extracted > from my experiments playing with stateless jsf: > > public class StatelessViewHandler extends ViewHandlerWrapper > { > > @Override > public UIViewRoot restoreView(FacesContext context, String viewId) > { > InitialViewCache ivch = InitialViewCache.getInstance(context); > ViewHandler viewHandler = context.getApplication().getViewHandler(); > String logicalViewId = viewHandler.deriveLogicalViewId(context, > viewId); > > if (ivch.isMarkedAsStateless(rawViewId)) > { > > > The idea is be careful an use always the logical viewId, and when you > are not sure call viewHandler.deriveLogicalViewId(context, viewId) . > > regards, > > Leonardo Uribe > > 2012/3/14 Thomas Andraschko <[email protected]>: > > Hi Leonardo, > > > > how can i get the viewId/deriveLogicalViewId in initView()? > > Maybe i can change this stuff the next weeks. > > > > Thanks, > > Thomas > > > > > > 2012/3/14 Leonardo Uribe <[email protected]> > >> > >> Hi > >> > >> 2012/3/14 PEREZ ALCAIDE JESUS <[email protected]>: > >> > Hello, > >> > > >> > > >> > > >> > I’m creating a custom ViewHandler in order to cache the component tree > >> > whenever is possible. I’m following the idea of “stateless JSF” to > >> > improve > >> > performance. > >> > > >> > >> Ok. Please be sure to read the latest discussion about this topic: > >> > >> > >> > http://markmail.org/message/24sbs2ltnrql7swz?q=[core]+discussion+about+stateless+jsf+implementation > >> > >> > > >> > > >> > My question is about > >> > DefaultFaceletsStateManagementStrategy.restoreView() > >> > method. In this method, you are calling > >> > ViewMetadata.createMetadataView() > >> > which ends up calling ViewHandler.createView to create the UIViewRoot > >> > used > >> > for metadata and a ViewMetadataFacelet to populate it. > >> > > >> > > >> > > >> > But this UIViewRoot (created for metadata) is used later to build the > >> > ‘real’ > >> > view. Why? > >> > > >> > >> That is for performance reasons. Suppose a request is received with some > >> query params. To process them, it is only necessary to build the > metadata > >> and then if a navigation occur by some condition, the new view can be > >> build, preventing the overhead associated with build the first view. > >> > >> > I think that a new UIViewRoot should be created for the real view, > >> > because > >> > metadata-view and real-view use different Facelets to populate the > view. > >> > > >> > > >> > > >> > Also, in the method > DefaultFaceletsStateManagementStrategy.restoreView() > >> > you > >> > are calling the static method > ViewMetadata.getViewParameters(UIViewRoot) > >> > on > >> > an instance of ViewMetadata (I think this should be fixed) and the > >> > Collection of UIViewParameters returned is not processed. > >> > > >> > > >> > >> That's by JSF 2.0 spec. > >> > >> > > >> > I wonder if ViewMetadata should be used in this method. I cannot see > any > >> > processing related to metadata happening here. > >> > > >> > > >> > >> It should be, because if we don't Partial State Saving algorithm will > >> break. The > >> view should be build on restoreView just like the first time + update > >> the "delta" > >> information. > >> > >> > > >> > Hope you have understood me. > >> > > >> > > >> > >> Yes, from my side, I can read the mail without problem. The idea > proposed > >> in "stateless JSF" is feasible, but it requires some changes like: > >> > >> - Use ConcurrentHashMap/ConcurrentLRUCache instead synchronized blocks. > >> - Use buildView instead clone the view to generate a new one. > >> - Use a combination of viewId/deriveLogicalViewId() > >> > >> Suggestions and contributions are welcome. > >> > >> regards, > >> > >> Leonardo Uribe > >> > >> > > >> > > >> > > >> > Un saludo, > >> > > >> > > >> > > >> > Jesús Pérez Alcaide > >> > > >> > Lab. Banksphere - Runtime > >> > > >> > Tlf: 91 470 5223 > >> > > >> > > >> > > >> > > >> > > >> > > >> > *********************AVISO LEGAL ********************** > >> > Este mensaje es privado y confidencial y solamente para la persona a > la > >> > que > >> > va dirigido. Si usted ha recibido este mensaje por error, no debe > >> > revelar, > >> > copiar, distribuir o usarlo en ningún sentido. Le rogamos lo comunique > >> > al > >> > remitente y borre dicho mensaje y cualquier documento adjunto que > >> > pudiera > >> > contener. No hay renuncia a la confidencialidad ni a ningún privilegio > >> > por > >> > causa de transmisión errónea o mal funcionamiento. > >> > Cualquier opinión expresada en este mensaje pertenece únicamente al > >> > autor > >> > remitente, y no representa necesariamente la opinión de ISBAN, a no > ser > >> > que > >> > expresamente se diga y el remitente esté autorizado para hacerlo. > >> > Los correos electrónicos no son seguros, no garantizan la > >> > confidencialidad > >> > ni la correcta recepción de los mismos, dado que pueden ser > >> > interceptados, > >> > manipulados, destruidos, llegar con demora o incompletos, o con virus. > >> > ISBAN > >> > no se hace responsable de los cambios, alteraciones, errores u > omisiones > >> > que > >> > pudieran hacerse al mensaje una vez enviado. > >> > Este mensaje sólo tiene una finalidad de información, y no debe > >> > interpretarse como una oferta de venta o de compra de valores ni de > >> > instrumentos financieros relacionados. > >> > > >> > **********************DISCLAIMER***************** > >> > This message is private and confidential and it is intended > exclusively > >> > for > >> > the addressee. If you receive this message by mistake, you should not > >> > disseminate, distribute or copy this e-mail. Please inform the sender > >> > and > >> > delete the message and attachments from your system. No > confidentiality > >> > nor > >> > any privilege regarding the information is waived or lost by any > >> > mistransmission or malfunction. > >> > Any views or opinions contained in this message are solely those of > the > >> > author, and do not necessarily represent those of ISBAN, unless > >> > otherwise > >> > specifically stated and the sender is authorized to do so. > >> > E-mail transmission cannot be guaranteed to be secure, confidential, > or > >> > error-free, as information could be intercepted, corrupted, lost, > >> > destroyed, > >> > arrive late or incomplete, or contain viruses. ISBAN does not accept > >> > responsibility for any changes, errors or omissions in the contents of > >> > this > >> > message after it has been sent. > >> > This message is provided for informational purposes and should not be > >> > construed as a solicitation or offer to buy or sell any securities or > >> > related financial instruments. > > > > >
