- ValueBinding.getValue(): null
- ValueBinding.setValue() : javax.faces.el.PropertyNotFoundException:
Base is null: .nullTestBean
- ValueBinding.getType() : javax.faces.el.PropertyNotFoundException:
Base is null: .nullTestBean
Same result with RI and MyFaces.
Exception with getType() is a issue too ( similar to ADFFACES-151),
input text renderer tries to get defaut converter for unresolvable value
binding.
Completion of previous use case: consider
tr:inputText binding=#{bean.component}
valueChangeListener="#{bean.aListener}"
value="#{testBean.nullTestBean.name}".
tr:inputText still should render input element (not-readOnly) because
users want:
- read value directly with component.getValue()
- get new value in valueChangeListener
Martin
Adam Winer píše v So 07. 10. 2006 v 07:32 -0700:
> 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
> > > >
> >
> >
