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 implementation. Especially if that interface only
returns a Boolean. An annotation marker might be a better thing to
use if you need to return exceptions with multiple origins or if these
wrapper exceptions can all come from the same base exception, a
special Trinidad exception type would be much more efficient because
we could simply return an instanceof and/or provide overloadable logic
to determine if logging is needed.
Just my .02, but I'm good with it.. ;)
Scott
On Feb 16, 2011, at 5:46 PM, Blake Sullivan <blake.sulli...@oracle.com> 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
>>>>>>>
>>>>>>>
>
