myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject Re: Question about DefaultFaceletsStateManagementStrategy
Date Wed, 14 Mar 2012 19:44:27 GMT
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