: Resolved (was: Patch Available)
Thanks to Martin Koci for provide this patch
UIInput.resetValue() throws NPE when no FacesContext available
--
Key: MYFACES-3434
URL: https
UIInput.resetValue() throws NPE when no FacesContext available
--
Key: MYFACES-3434
URL: https://issues.apache.org/jira/browse/MYFACES-3434
Project: MyFaces Core
Issue Type: Bug
[
https://issues.apache.org/jira/browse/MYFACES-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Kočí updated MYFACES-3434:
-
Status: Patch Available (was: Open)
UIInput.resetValue() throws NPE when no FacesContext
-1
Sorry, I cannot agree.
The API doc of resetValue() tells you why:
Convenience method to reset [..]
A utility like method for convenience like this one does not belong
to an interface. It does not add any behavioural function.
UIInput is not an interface but a (base) class, so it is ok to have
Although I'm -1 also because of backward compatibility, I also felt that it
should have been added to the interface to start with as it simplifies many
loops used for reseting EditableValueHolder of the whole tree. You cannot
use instanceof UIInput for those as Trinidad input components, for
Why not use the last if alone?
if (component instanceof EditableValueHolder)
{
EditableValueHolder holder = (EditableValueHolder)component;
holder.setValue(null);
holder.setSubmittedValue(null);
holder.setLocalValueSet(false);
holder.setValid(true);
}
Every UIInput is an
Matze, do you have any concrete use case that could confirm your POV?
a hack like the mentioned utility does it. But using clean interfaces would
be more appreciated.
Originally this email should go the the RI list, b/c I am hoping that
the interface
changes in JSF2 (for some reasons). We here
On Jan 15, 2008 4:16 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
We here can only talk... The spec itself is made behind closed doors ;-)
Not really closed
ajar would be a better word: at least everyone is allowed to comment
on early drafts
;-)
--Manfred
As I said, I see from the backwards compatibility why it was done.
On Jan 15, 2008 7:02 AM, Manfred Geiler [EMAIL PROTECTED] wrote:
Why not use the last if alone?
because this all is already done in JSF ...
if (component instanceof EditableValueHolder)
{
EditableValueHolder holder =
Personally, considering there's always backward compatibility issues anyway,
I wouldn't mind seeing some new ones if it was to allow JSF to be much
faster, easier to use and more extensible. Like standardizing FacesBean for
instance. If done correctly, it would give a decent speed boost, allow
nice...
On Jan 15, 2008 7:23 AM, Manfred Geiler [EMAIL PROTECTED] wrote:
On Jan 15, 2008 4:16 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
We here can only talk... The spec itself is made behind closed doors ;-)
Not really closed
ajar would be a better word: at least everyone is allowed
Yes, which mean that I might make such propositions or support them, but I'm
not the only member and I'm pretty such that some members see apparent
backward compatibility to be a precept above anything else.
~ Simon
On Jan 15, 2008 11:35 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
aren't
but, a move to JSF 2 is MUCH bigger than to 1.2 (from 1.1)
-M
On Jan 15, 2008 9:57 AM, Simon Lessard [EMAIL PROTECTED] wrote:
Yes, which mean that I might make such propositions or support them, but I'm
not the only member and I'm pretty such that some members see apparent
backward
And I sure hope it will.
On Jan 15, 2008 1:03 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
but, a move to JSF 2 is MUCH bigger than to 1.2 (from 1.1)
-M
On Jan 15, 2008 9:57 AM, Simon Lessard [EMAIL PROTECTED] wrote:
Yes, which mean that I might make such propositions or support them,
Hi,
the resetValue() method was added directly to UIinput, instead to a
proper interface (EditableValueHolder).
I guess this was done, to not break impls of that interface.
IMO this is wrong and should (at least in JSF2) be part of the
EditableValueHolder interface.
Since JSF2 will bring much
15 matches
Mail list logo
