Hi Michael,

Please use

FacesContext facesContext = FacesContext.getCurrentInstance();
facesContext.getApplication().getExpressionFactory().createValueExpression(facesContext.getELContext(),
"#{beanName}", Object.class).getValue(facesContext.getELContext());

to resolve the managed bean in private Object getManagedBean(String
beanName).

In the setter you can do the following:

FacesContext facesContext = FacesContext.getCurrentInstance();
facesContext.getApplication().getExpressionFactory().createValueExpression(facesContext.getELContext(),
"#{beanName}", Object.class).setValue(facesContext.getELContext(), o);

And to your question: Why are these EL conditions working in outputText tags
but not in others like
t:saveSate, t:inputText, f:selectItems and so on after form submission?
It's the same EL impl, or?

You can use ? : for ValueExpressions which are only used to GET a value
(e.g. h:outputText). If you use them in a ValueExpression which might also
SET the value of the property, you will get an Exception (e.g. h:inputText).

Regards,
Jakob


2009/12/17 Michael Heinen <[email protected]>

> Why are these EL conditions working in outputText tags but not in others
> like
> t:saveSate, t:inputText, f:selectItems and so on after form submission?
> It's the same EL impl, or?
>
> I used these EL conditions really often and I'm currently not able to
> convert them or move them into a managed bean.
> This is another blocker for my migration.
>
> Michael
>
> -----Original Message-----
> From: Michael Heinen [mailto:[email protected]]
> Sent: Donnerstag, 17. Dezember 2009 15:28
> To: Jakob Korherr; MyFaces Discussion
> Subject: RE: JspPropertyNotWritableException - Illegal Syntax for Set
> Operation after update to 1.2
>
> Thanks for the samples Jakob.
> I tried it this way but t:savestate does not work so far.
>
> Sample jsp:
> works: <t:saveState id="foo" value="#{foobean}"/>
> works not: <t:saveState id="aaa" value="#{ELUtilController.mybean}"/>
>
> public class ELUtilController {
>  private Object getManagedBean(String beanName){
>    FacesContext fc = FacesContext.getCurrentInstance();
>    return fc.getApplication().getVariableResolver().resolveVariable(fc,
> beanName);
>   //the deprecated way
>  }
>
>  public Object getMybean(){
>    if (user.isRestricted()){
>      return getManagedBean("bean1");
>    }
>    return getManagedBean("bean2");
>  }
>
>  public void setMybean(Object o){
>    //what’s to do here???
>  }
> }
>
>  “bean1” is currently instantiated again during submit which should not
> occur.
> “foobean” is not instantiated a second time.
>
> What should I do in the setter setMybean? The passed object is “bean1”.
> Do I have to call anything in setMybean?
>
> “bean1” is also instantiated only one time if I use it directly:
> <t:saveState id="bbb" value="#{bean1}"/>
>
>
> Michael
>
>
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Jakob Korherr
> Sent: Donnerstag, 17. Dezember 2009 12:35
> To: MyFaces Discussion
> Cc: Michael Heinen
> Subject: Re: JspPropertyNotWritableException - Illegal Syntax for Set
> Operation after update to 1.2
>
> Hi Michael,
>
> No problem ;)
>
> I don't think it's a bug in the Unified EL impl of tomcat. It's rather a
> specification bug or just not wanted by the spec. However, I don't know the
> unified EL spec very well, so I don't know it exactly.
>
> To your problem: you can resolve any EL expression in the managed bean
> method using the ExpressionFactory, for example:
>
> FacesContext facesContext = FacesContext.getCurrentInstance();
> facesContext.getApplication().getExpressionFactory().createValueExpression(facesContext.getELContext(),
> "#{searchEntry.type=='dateForm'}",
> Boolean.class).getValue(facesContext.getELContext());
>
> This is also true for those objects, which are generated by the t:dataList,
> because the property in the managed bean is evaluated while the objects are
> in the request scope. Just try it!
>
> However, a better method would be to use the binding attribute of the
> t:dataList, for example binding = #{bean.myDataTable}. Then you can access
> the current row data inside the managed bean with myDataTable.getRowData()
> (the type of myDataTable is
> org.apache.myfaces.component.html.ext.HtmlDataTable).
>
> Hope this helps!
>
> Regards,
> Jakob
>
> 2009/12/17 Michael Heinen <[email protected]<mailto:
> [email protected]>>
> I just tried the latest 6.0.20 without success.
>
> Do you think it's Bug in tomcat's EL impl?
> If so I'll try to talk with some tomcat guys but this will take some time I
> fear.
>
> Michael
>
>
> -----Original Message-----
> From: Michael Heinen [mailto:[email protected]<mailto:
> [email protected]>]
> Sent: Donnerstag, 17. Dezember 2009 11:40
> To: MyFaces Discussion
> Subject: RE: JspPropertyNotWritableException - Illegal Syntax for Set
> Operation after update to 1.2
>
> I was afraid of something like this.
>
> Moving this logic into managed beans is not so easy because they are not
> always accessible, or?
> For some simple expressions it can be done but what about expressions in
> nested lists?
>
> Sample
> <t:dataList id="outer" var="search"
>  <t:dataList id="inner" var="searchEntry"
>  <t:inputText
>
>  
> value="#{searchEntry.type=='dateFrom'?search.attributes[searchEntry.name].begin:search.attributes[searchEntry.name].end}"/>
>
> Local iteration var searchEntry does not know search which is in an outer
> container and vice versa.
> And I cannot pass variables (I don’t use facelets).
>
> Isn’t this a major functionality loss?
> Can I use another impl. of the unified EL? If yes which one would you
> recommend?
>
> Michael
>
>
> From: [email protected]<mailto:[email protected]> [mailto:
> [email protected]<mailto:[email protected]>] On Behalf Of
> Jakob Korherr
> Sent: Donnerstag, 17. Dezember 2009 10:54
> To: MyFaces Discussion
> Cc: Michael Heinen
> Subject: Re: JspPropertyNotWritableException - Illegal Syntax for Set
> Operation after update to 1.2
>
> Hi Michael,
>
> Due to the change to the Unified EL from MyFaces 1.1 to 1.2 some EL related
> things changed. The problem you're describing is one of those, I'm afraid.
>
> Looking at the first item in the stacktrace you can see that the Exception
> does not come from MyFaces, but from tomcat's implementation of the Unified
> EL: org.apache.jasper.el.JspValueExpression.
>
> You can workaround this by moving the logic to a managed bean property.
>
> Regards,
>
> Jakob Korherr
>
> 2009/12/17 Michael Heinen <[email protected]<mailto:
> [email protected]><mailto:[email protected]<mailto:
> [email protected]>>>
> Hi,
>
> are conditional Expressions not allowed anymore in value attributes in JSF
> 1.2?
>
> Stack:
> Caused by: org.apache.jasper.el.JspPropertyNotWritableException:
> /pages/search.jsp(13,2)
> '#{sessionScope.visit.user.restrictedToSearchInBatches?FlatBatchForReviewerCacheBean:NullBean}'
> Illegal Syntax for Set Operation
>              at
> org.apache.jasper.el.JspValueExpression.setValue(JspValueExpression.java:88)
>              at
> org.apache.myfaces.custom.savestate.UISaveState.restoreState(UISaveState.java:125)
>              at
> javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:849)
>              ... 48 more
>
> Tag:
> <t:saveState id="flatBatchForReviewerCacheBean"
> value="#{user.allowedToDoIt?FlatBatchForReviewerCacheBean:NullBean}"/>
>
> It is working if I use either FlatBatchForReviewerCacheBean or NullBean
> without the condition.
>
>
> Input tags are also not working with conditions in the value attribute:
> Message:
> org.apache.jasper.el.JspPropertyNotWritableException:
> /pages/search.jsp(154,14)
> '#{searchEntry.type=='dateFrom'?search.attributes[searchEntry.name].begin:search.attributes[searchEntry.name].end}'
> Illegal Syntax for Set Operation
>
> JSP snippet
> <t:dataList id="taxList"
>  value="#{MyController.fields}"
>  var="searchEntry" ... >
>
>  <t:inputText id="s_date"
>
>  
> value="#{searchEntry.type=='dateFrom'?search.attributes[searchEntry.name].begin:search.attributes[searchEntry.name].end}">
>  </t:inputText>
>
> Both tags worked well with myfaces 1.1.6 and tomahawk 1.1.7 but not with
> myfaces 1.2.8 and tomahawk12_1.1.9
>
> Is it a bug?
> Do I have to change anything or is there a workaround?
>
> Michael
>
>

Reply via email to