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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> >
