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-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
