onActivate UnknownValueException

[Jens Breitenstein <ma...@j-b-s.de>]

Hi All!

I use an enum as activation context parameter. Unfortunately in case the 
enum changes or more likely the user has a typo in the url Tapestry is 
unable to coerce the url param to enum and fails by throwing an 
exception (fair enough). Instead of using onActivate parameters I 
switched to EventContext to get fine grained control here by simply 
catching the exception when coercing the enum from a given event context 
value. I wonder if there es a more elegant solution currently build in? 
If not what do you think about:

a) can't we create a new Tapestry annotation like 
"CoerceExceptionDefaultsToNull" or something similar to allow this 
annotation for parameters in onActivate (I know we can not limit it to 
onActivate, but...) and supress the original exception (maybe not that 
developer friendly). This introduces "if (null == xyz)" cascades but at 
least we won't see an exception at the client side.

or

b) a callback like "Object onActivationCoercionError(final Object value, 
final Class destinationClass, final Exception e)"  to make the developer 
aware of problems, allow providing a default value and Tapestry 
continues normally by calling the best fitting onActivate method afterwards?

Maybe EventContext is the route to go for proper error handling, but my 
gut feeling is we are loosing much of Tapestry's onActivation magic.
Any thoughts?

Jens


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: onActivate UnknownValueException

[Andreas Fink <fi...@googlemail.com>]

Hi Jens.

I think it depends on what you want to do after finding out that you cannot coerce the parameter.
If you want to redirect to another page the logic should still be in the page class or maybe a T5-RequestFilter where you can move that logic/redirection code to.

If you want to "rewrite" to a default value, i would rather go for a custom type coercer like below.
Such a service could also do lookups in a persistence layer and provide meaningful defaults or notifications....

public static void bind(final ServiceBinder binder)
{
	binder.bind(MyEnumTypeCoercerInterface.class, MyEnumTypeCoercerImpl.class);
}

public void contributeTypeCoercer(
		final Configuration<CoercionTuple<?, ?>> conf,
		final @Local MyEnumTypeCoercerInterface tc)
	{
	conf.add(new CoercionTuple<String, MyEnum>(String.class, MyEnum.class, tc.newString2MyEnum()));
	conf.add(new CoercionTuple<MyEnum, String>(MyEnum.class, String.class, tc.newMyEnum2String()));
}

public class MyEnumTypeCoercerImpl implements MyEnumTypeCoercerInterface
{

	public Coercion<String, MyEnum> newString2MyEnum()
	{
		return new Coercion<String, MyEnum>()
		{
			@Override public MyEnum coerce(final String someString)
			{
				// logic be here

				return someEnum;
			}
		};
	}

	public Coercion<String, MyEnum> newMyEnum2String()
	{
		return new Coercion<MyEnum, String>()
		{
			@Override public String coerce(final MyEnum someEnum)
			{
				// logic be here

				return someString;
			}
		};
	}

}


On May 4, 2013, at 16:41 , Jens Breitenstein wrote:

> Hi All!
> 
> I use an enum as activation context parameter. Unfortunately in case the enum changes or more likely the user has a typo in the url Tapestry is unable to coerce the url param to enum and fails by throwing an exception (fair enough). Instead of using onActivate parameters I switched to EventContext to get fine grained control here by simply catching the exception when coercing the enum from a given event context value. I wonder if there es a more elegant solution currently build in? If not what do you think about:
> 
> a) can't we create a new Tapestry annotation like "CoerceExceptionDefaultsToNull" or something similar to allow this annotation for parameters in onActivate (I know we can not limit it to onActivate, but...) and supress the original exception (maybe not that developer friendly). This introduces "if (null == xyz)" cascades but at least we won't see an exception at the client side.
> 
> or
> 
> b) a callback like "Object onActivationCoercionError(final Object value, final Class destinationClass, final Exception e)"  to make the developer aware of problems, allow providing a default value and Tapestry continues normally by calling the best fitting onActivate method afterwards?
> 
> Maybe EventContext is the route to go for proper error handling, but my gut feeling is we are loosing much of Tapestry's onActivation magic.
> Any thoughts?
> 
> Jens
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org