Hi:
This is for JIRA TRINIDAD-2038, please let me know your suggestion.
There are cases that exception is thrown in update model phase, like
model layer validation failure, by model outside of JSF and the
exception is also handled and reported outside of JSF. To avoid the
component's local
Hello Hongbing,
You mentioned that exceptions get thrown by model layer outside of JSF. Can you
give an e.g., of when this might occur?
How exactly will the interface get used?
Thanks
Pavitra
On 2/16/2011 1:01 PM, Hongbing wrote:
Hi:
This is for JIRA TRINIDAD-2038, please let me know your
Hi Pavitra:
It can happen in update model phase. For example, Model layer throws
exception when attribute value validation fails, binding layer detects
it and re-throwd new exception with the new interface to JSF. JSF then
can handle it accordingly.
thanks,
Hongbing
On 2/16/2011 2:09 PM,
Hogbing,
I'm taking a look at the bug now but just so I understand.. When you
refer to JSF, I assume you mean the Trinidad renderkit. Is that
correct?
Scott
On Feb 16, 2011, at 4:23 PM, Hongbing hongbing.w...@oracle.com wrote:
Hi Pavitra:
It can happen in update model phase. For example,
Hi Scott:
One example is in the following
UIXEditableValue.updateModel(FacesContext context) code,
public void updateModel(FacesContext context)
{
try
{
Object localValue = getLocalValue();
expression.setValue(context.getELContext(), localValue);
If this exception is handled, why is it rethrown? What would you
expect Trinidad to do in this case?
On Feb 16, 2011, at 5:37 PM, Hongbing hongbing.w...@oracle.com wrote:
Hi Scott:
One example is in the following UIXEditableValue.updateModel(FacesContext
context) code,
public void
In an ideal world, validation occurs in PROCESS_VALIDATIONS phase of JSF
lifecycle, so there shouldn't be any problems pushing the validated
value to the model.
Our Trinidad renderkit implements the lifecycle in such a way that after
PROCESS_VALIDATIONS phase, the submitted value is cleared,
The issue isn't that the problem has been handled by the model. It
hasn't. Therefore the model has to throw a RuntimeException in this
case so that the component knows to preserve its local value. That's
all good.
The problem occurs if the model has its own mechanisms for reporting
Ahh cool. Thanks Blake. That clears things up consoderably. I guess
I'm cool with it but I'm wondering if this might not be better served
by a RUNTIME annotation or even a new Trinidad exception class.
Having an interface on an exception seems a bit silly to me because it
requires some
Sounds good. Thanks.
+1 with minor typo corrections in comments.
/**
* Interface for exceptions that tells whether the exception needs to
be reported.
* If an exception is thrown during the JSF _lifecycle and already_
reported, then
* it should let JSF know not to report it again.
*
10 matches
Mail list logo
