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.
