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 20:05:38 GMT
On 10/7/06, Martin Koci <Martin.Koci@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 <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