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.
*
*/
On 2/16/2011 4:45 PM, Blake Sullivan wrote:
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
problems. In that case, we want to avoid reporting the same problem
twice and that is where the interface comes in. The model wants to
tell the view that there was a problem, but that the model will take
care of reporting it, so the view needn't bother.
-- Blake Sullivan
On 2/16/11 4:39 PM, Scott O'Bryan wrote:
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 updateModel(FacesContext context)
{
....
try
{
Object localValue = getLocalValue();
expression.setValue(context.getELContext(), localValue);
setValue(null);
setLocalValueSet(false);
if (_LOG.isFiner())
{
_LOG.finer("Wrote value {0} to model {1} in component {2}",
new Object[]{localValue,
expression.getExpressionString(),
this});
}
}
catch (RuntimeException e)
{
...
expression.setValue(context.getELContext(), localValue) calls
binding code and then the model's code, where exception can be thrown.
In the catch part, we want to skip reporting the exception if it
is handled by model/controller code.
Thanks,
Hongbing
On 2/16/2011 4:23 PM, Scott O'Bryan wrote:
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, 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, Pavitra Subramaniam wrote:
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 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 value getting reset to null, JSF
needs to be notified when it happens. The proposed solution is
to re-throw a special exception to JSF to notify it and also let
JSF know whether it needs to report the exception.
Here is the interface of the exception:
package org.apache.myfaces.trinidad.context;
/**
* Interface for exceptions that tells whether the exception
needs to be reported.
* If an exception is thrown during JSF lifycycle and aleady
reported, then it should let
* JSF know not to report it again.
*
*/
public interface Reportable
{
/**
* Return false if JSF doesn't need to report this exception,
otherwise true.
*/
public boolean isReportingMessage();
}
Thanks,
Hongbing
