incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: ADFFACES-214: EditableValueRenderer does not handle EvaluationException in method getReadOnly
Date Sat, 07 Oct 2006 14:32:22 GMT
Martin,

When your bean is constructed this way, what are the results of
calling:
 - ValueBinding.getValue()
 - ValueBinding.setValue()
 - ValueBinding.getType()

-- Adam

On 10/7/06, Martin Koci <Martin.Koci@aura.cz> wrote:
>
> Hello,
>
> maybe it is a architecture problem in our appliaction, but sometimes we
> use following construction (example):
>
> // managed bean that has null property:
> public class TestBean {
>
>     private String name;
>
>     public String getName() {
>         return name;
>     }
>
>     // Not-initialized bean property
>     private TestBean nullTestBean;
>
>     public TestBean getNullTestBean() {
>         return nullTestBean;
>     }
> }
>
> Test jsp:
>
> <h:inputText id="riInputText" value="#{testBean.nullTestBean.name}" />
>
> <t:inputText id="tomahawkInputText"
> value="#{testBean.nullTestBean.name}" />
>
> <tr:inputText id="trinidadInputText"
> value="#{testBean.nullTestBean.name}" />
>
> h: and t: produce input box with no problem, but tr: throws  exception.
> Nevermind that valueBidning cannot be evaluated: for example there is
> other inputText in the same form. That inputText has a
> valueChangeListener and is auto-submitted and immediate. In
> valueChangeListener we can initialize nullTestBean property and call
> context.renderResponse(). Than if user submits whole form valueBidning
> can be evaulated and updateModel phase process normally.
>
> This case work right with RI, myfaces, tomahawk and ICEFaces Comunnity
> Edition.
>
> I don't think we should return true if exception occurs - valueBinding
> is not readOnly. Better description can be "we cannot say that
> valueBidning is readOnly or not so we return default value".
>
>
>
>
> Martin
>
> Arjuna Wijeyekoon píše v Pá 06. 10. 2006 v 12:27 -0700:
> > I agree with Adam,
> > I think an Exception while calling any of the methods on ValueBinding
> > (except for the setValue method) should be considered a bug in the
> > application and logged at
> > level WARNING.
> >
> > And in this case, we should return true
> > to indicate that the binding is readOnly (opt for the more restrictive
> > option when there are errors).
> >
> > --arjuna
> >
> >
> > On 10/6/06, Adam Winer <awiner@gmail.com> wrote:
> > >
> > > Martin,
> > >
> > > Looking at this bug and patch, I'm not sure of the right way to go.
> > >
> > > I'm worried about this;  if the exception is thrown constantly, that
> > > could be a significant performance problem.  I'm not at all sure that
> > > we wouldn't want to warn the developer (hence, _LOG.warning()).  Also,
> > > maybe returning true would be better than false here, since the value
> > > isn't writable.
> > >
> > > If we do catch the exception, what happens later when the value is
> > > actually retrieved for rendering?  Isn't that just going to generate
> > > another uncaught exception?
> > >
> > > -- Adam
> > >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message