You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by PEREZ ALCAIDE JESUS <jp...@servexternos.isban.es> on 2012/03/14 18:18:33 UTC
Question about DefaultFaceletsStateManagementStrategy
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.
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?
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.
I wonder if ViewMetadata should be used in this method. I cannot see any processing related to metadata happening here.
Hope you have understood me.
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.
Re: Question about DefaultFaceletsStateManagementStrategy
Posted by Thomas Andraschko <zo...@googlemail.com>.
Hi,
all right, thanks Leonardo!
Regards,
Thomas
2012/3/14 Leonardo Uribe <lu...@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 <zo...@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 <lu...@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 <zo...@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 <lu...@gmail.com>
> >> >>
> >> >> Hi
> >> >>
> >> >> 2012/3/14 PEREZ ALCAIDE JESUS <jp...@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.
> >> >
> >> >
> >
> >
>
Re: Question about DefaultFaceletsStateManagementStrategy
Posted by Leonardo Uribe <lu...@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 <zo...@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 <lu...@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 <zo...@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 <lu...@gmail.com>
>> >>
>> >> Hi
>> >>
>> >> 2012/3/14 PEREZ ALCAIDE JESUS <jp...@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.
>> >
>> >
>
>
Re: Question about DefaultFaceletsStateManagementStrategy
Posted by Thomas Andraschko <zo...@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 <lu...@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 <zo...@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 <lu...@gmail.com>
> >>
> >> Hi
> >>
> >> 2012/3/14 PEREZ ALCAIDE JESUS <jp...@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.
> >
> >
>
Re: Question about DefaultFaceletsStateManagementStrategy
Posted by Leonardo Uribe <lu...@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 <zo...@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 <lu...@gmail.com>
>>
>> Hi
>>
>> 2012/3/14 PEREZ ALCAIDE JESUS <jp...@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.
>
>
Re: Question about DefaultFaceletsStateManagementStrategy
Posted by Thomas Andraschko <zo...@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 <lu...@gmail.com>
> Hi
>
> 2012/3/14 PEREZ ALCAIDE JESUS <jp...@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.
>
RE: Question about DefaultFaceletsStateManagementStrategy
Posted by PEREZ ALCAIDE JESUS <jp...@servexternos.isban.es>.
Hi Leonardo, thanks for your quick reply.
I'm following the idea of "stateless JSF" but adapted to my particular scenario. I have read the discussion and based on your classification of views, my views are "static views".
So, my implementation is based on pooling component tree instances and reuse it for render the same view on different requests. In my fist tests, this have improved the performance on +400% on hits per second.
I'm using a custom ViewHandler to manage that pool. In method createView() I check if there is an instance already pooled for the requested view, if so return it, and if not use de standard ViewHandler to create a new one.
But the problem I have found is that I cannot differentiate (in a standard way, suitable for any implementation of JSF) when this method (ViewHandler.createView()) is called for the "real-view" or for the "metadata-view".
Un saludo,
Jesús Pérez Alcaide
Lab. Banksphere - Runtime
Tlf: 91 470 5223
-----Mensaje original-----
De: Leonardo Uribe [mailto:lu4242@gmail.com]
Enviado el: miércoles, 14 de marzo de 2012 19:58
Para: MyFaces Development
Asunto: Re: Question about DefaultFaceletsStateManagementStrategy
Hi
2012/3/14 PEREZ ALCAIDE JESUS <jp...@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.
*********************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.
Re: Question about DefaultFaceletsStateManagementStrategy
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
2012/3/14 PEREZ ALCAIDE JESUS <jp...@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.