myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Andraschko <zoi...@googlemail.com>
Subject Re: Question about DefaultFaceletsStateManagementStrategy
Date Wed, 14 Mar 2012 20:13:09 GMT
Hi,

all right, thanks Leonardo!

Regards,
Thomas


2012/3/14 Leonardo Uribe <lu4242@gmail.com>

> 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 <zoigln@googlemail.com>:
> > 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 <lu4242@gmail.com>
> >>
> >> 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 <zoigln@googlemail.com>:
> >> > 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 <lu4242@gmail.com>
> >> >>
> >> >> Hi
> >> >>
> >> >> 2012/3/14 PEREZ ALCAIDE JESUS <jperealc@servexternos.isban.es>:
> >> >> > 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.
> >> >
> >> >
> >
> >
>

Mime
View raw message