Thanks! Wow, that's some bizarro EL behavior. Can't imagine
why it got specified that way (if it is, in fact, specified to
do that). I don't know why you should be able to get a value,
but not find out if it's read-only or get its type. IMO, if
getValue() returns safely, isReadOnly() and getType()
must also return safely (in this case, should be "true"
and "null").
BTW, have you tried this with JSF 1.2/JSP 2.1?
Or, at least with Facelets (which'd be the same EL engine)?
I'm gonna follow up with the EL spec folks at Sun.
-- Adam
On 10/7/06, Martin Koci <[EMAIL PROTECTED]> wrote:
- 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
> > > >
> >
> >
