On 06/03/2013 20:02, Leonardo Uribe wrote:
Hi

There are good reasons to avoid use VariableMapper. This class is used
when the EL expressions are built to store some values required to
resolve the expression later, making the expression not cacheable,
because the content of VariableMapper could change at any time and in
that way, it is not possible to reuse the same expression.

The wrappers used for EL expressions are there to ensure proper
context initialization. For example, when the EL expression is
evaluated, the reference for the composite component must be pushed on
to the stack.

This process is done by facelets, so create a value expression like
#{cc} programatically will not have the same effect as if it is
created by facelets compiler (if it is located inside composite
component .xhtml file).

If you need some kind of global context in your pages, the best way is
write a custom EL resolver. Other option is write an specific facelets
function, and pass the reference to the composite component to
retrieve the specified context and finally resolve it properly. For
example:

#{utils:context(cc).selected.attribute1}

Really I don't know what you are trying to do, but I hope these ideas
could help.
Thank you for this reply.

My application manages collections of tens of types.

It is some kind of CRUD + collections management.

As I do not like to copy paste code over and over, I wrote a lib that analyses those types to decide how they should be displayed or edited. It uses custom annotations and information provided by hibernate (all those type are hibernate objects). I call this information a "mapping".

For collections that should be displayed as a datatable, I use this mapping to dynamically instantiate columns
So, I have code like :

 <p:dataTable ... var="elutit">
                <c:forEach items="#{mapper.mappings}" var="curProp">
                    <my:displayColumn mapper="#{mapper}" bean="elutit"
mappingDesc="#{curProp}"/>
                </c:forEach>
</p:dataTable>

my:displayColumn is a custom class extending Column that will use the mapping and the bean to correctly display a property as a column. To ensure dynamic update, the values and parameters of the display controls added as children of this custom column are set as ValueExpression-s.

In this datatable example I have no problem, as the bean name (here "elutit") is local to the control. Value expression will be for example #{elutit.property1}

For generic editions, I have controls that derives from layouting controls such as panels. As I like PrimeFaces, I most often use a control derivating from PanelGrid. This control takes various parameters as attributes : the mapper, the bean, etc. Similar to the dataTable, it adds edition controls as children, setting their values with ValueExpression-s.


The bean to display is specified as an attribute of this custom control, with an EL expression : #{myBean}. I need to get a hand on an EL expression that can reference myBean in the ValueExpressions I generate for display controls. I use this EL Expression as a parameter of my generated ValueExpressions In some cases, a property value will not be just #{myBean.property1} but #{my:customFunction(myBean)}, with #{my:customFunction(<inst>)} specified in mapping configuration and <inst> replaced by the "right" EL expression.

Following your advice, I took a look at custom EL resolvers. It is definitely a good solution for mapping "absolute" names. I did not see how it can help me in my case of a custom control used inside a tag file.

In this case, you can have the top level variable A specified as parameter B to the tag component, using it as parameter C of the custom component. I need a way to get track of these successive mappings. Ideally, I would be able to instantiate my ValueExpressions with the exact same context, and so the same variable mappings.


Thanks again for your attention, I hope my English makes sense...

Best regards,

Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|

Reply via email to