You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Martin Koci <Ma...@aura.cz> on 2006/10/07 10:20:00 UTC
Re: ADFFACES-214: EditableValueRenderer does not handle
EvaluationException in method getReadOnly
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 <aw...@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
> >
Re: ADFFACES-214: EditableValueRenderer does not handle EvaluationException in method getReadOnly
Posted by Adam Winer <aw...@gmail.com>.
On 10/7/06, Martin Koci <Ma...@aura.cz> 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
I really disagree here. It has to be read-only: otherwise,
you're going to get an exception during Update Model.
IMO, the auto-readOnly functionality of Trinidad input
components is a very valuable feature, and it's
the whole reason why I pushed to get an isReadOnly()
feature into the JSF (and now JSP) EL.
-- Adam
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 <Ma...@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 <aw...@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
> > > > >
> > >
> > >
>
>
Re: ADFFACES-214: EditableValueRenderer does not handle EvaluationException in method getReadOnly
Posted by Adam Winer <aw...@gmail.com>.
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 <Ma...@aura.cz> 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 <Ma...@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 <aw...@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
> > > > >
> > >
> > >
>
>
Re: ADFFACES-214: EditableValueRenderer does not handle
EvaluationException in method getReadOnly
Posted by Martin Koci <Ma...@aura.cz>.
- 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 <Ma...@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 <aw...@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
> > > >
> >
> >
Re: ADFFACES-214: EditableValueRenderer does not handle EvaluationException in method getReadOnly
Posted by Adam Winer <aw...@gmail.com>.
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 <Ma...@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 <aw...@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
> > >
>
>