Hi, all right, thanks Leonardo!
Regards, Thomas 2012/3/14 Leonardo Uribe <[email protected]> > Hi > > Really I only did a "proof of concept" prototype, fixing the problems > already described and then check its performance against normal jsf. > It is not a fully functional prototype and involved some changes in > myfaces core internals. > > For now my intention in this topic is give some ideas about what can > we do. For the next release, the efforts are focused on improve > myfaces algorithm. Almost all the code has been already committed. > > Maybe after next release I'll check stateless jsf again and propose > something in MYFACES-3465. > > regards, > > Leonardo > > 2012/3/14 Thomas Andraschko <[email protected]>: > > 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. > >> > > >> > > > > > >
