You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Fisher, Brice A" <ba...@sandia.gov> on 2007/05/22 17:21:36 UTC
T5: Type Coercion vs. Translator
I have a bean that returns an Id as a java.util.UUID. Tapestry 5
can't translate this into anything it can display, so I get a:
---
java.lang.IllegalArgumentException
No adapter from type java.util.UUID to type
org.apache.tapestry.Translator is available (registered types are
java.lang.Double, java.lang.Integer, java.lang.Long, java.lang.String).
---
So, I added a Type Coercion to my AppModule to coerce UUID's to
Strings, but that's not sufficient. Do I need to coerce UUIDs to a
Translator (and if so, how, as it's not clear how a StringTranslator
would be constructed)? Or is there some other interface to register a
type with the Translator?
Thanks,
- Brice
Re: T5: Type Coercion vs. Translator
Posted by tovarisch <is...@gmail.com>.
I'm a bit confused about coercion and translators. What if I want to use
BigDecimal for two kind of data but with different representation (say 2 and
4 decimals)? I can create two named translators, but what about coercion?
Thanks.
Howard Lewis Ship wrote:
>
> There's (for the moment) two configurations that control translators.
> Here's the built-in contributions, provided by TapestryModule:
>
> /**
> * Contributes the basic set of default translators:
> * <ul>
> * <li>Integer</li>
> * <li>String</li>
> * <li>Long</li>
> * <li>Double</li>
> * </li>
> */
> public static void contributeTranslatorDefaultSource(
> MappedConfiguration<Class, Translator> configuration)
> {
> configuration.add(Integer.class, new IntegerTranslator());
> configuration.add(String.class, new StringTranslator());
> configuration.add(Long.class, new LongTranslator());
> configuration.add(Double.class, new DoubleTranslator());
> }
>
> /**
> * Contributes the basic set of named translators:
> * <ul>
> * <li>integer</li>
> * <li>string</li>
> * <li>long</li>
> * <li>double</li>
> * </ul>
> */
> public static void contributeTranslatorSource(
> MappedConfiguration<String, Translator> configuration)
> {
> // Fortunately, the translators are tiny, so we don't have to
> worry
> about the slight
> // duplication between this and TranslatorDefaultSource, though it
> is a pain to keep the two
> // organized (perhaps they should be joined together into a single
> service, where we
> // identify a name and a match type).
>
> configuration.add("integer", new IntegerTranslator());
> configuration.add("string", new StringTranslator());
> configuration.add("long", new LongTranslator());
> configuration.add("double", new DoubleTranslator());
> }
>
> The TranslatorDefaultSource is responsible for providing a translator
> based
> on the property type. The TranslatorSource is used (with the translator:
> binding prefix) to select a translator by name.
>
> The repetition is annoying and the two services may be merged together at
> some point.
>
> I don't think a UUID translator would be very complicated: there's a
> static
> fromString() method.
>
> It does make sense that there should be a default translator that
> leverages
> the TypeCoercer to perform translations to and from strings. Perhaps
> TranslatorDefaultSource is simply not needed -- scratch that: the
> translators are needed to generate client-side validation JavaScript (but
> a
> default translator would be useful, even if it could not handle
> client-side
> validation).
>
>
> On 5/22/07, Fisher, Brice A <ba...@sandia.gov> wrote:
>>
>> I have a bean that returns an Id as a java.util.UUID. Tapestry 5
>> can't translate this into anything it can display, so I get a:
>>
>> ---
>> java.lang.IllegalArgumentException
>> No adapter from type java.util.UUID to type
>> org.apache.tapestry.Translator is available (registered types are
>> java.lang.Double, java.lang.Integer, java.lang.Long, java.lang.String).
>> ---
>>
>> So, I added a Type Coercion to my AppModule to coerce UUID's to
>> Strings, but that's not sufficient. Do I need to coerce UUIDs to a
>> Translator (and if so, how, as it's not clear how a StringTranslator
>> would be constructed)? Or is there some other interface to register a
>> type with the Translator?
>>
>> Thanks,
>> - Brice
>>
>
>
>
> --
> Howard M. Lewis Ship
> TWD Consulting, Inc.
> Independent J2EE / Open-Source Java Consultant
> Creator and PMC Chair, Apache Tapestry
> Creator, Apache HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
>
--
View this message in context: http://www.nabble.com/T5%3A-Type-Coercion-vs.-Translator-tf3797064.html#a11138042
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Type Coercion vs. Translator
Posted by Howard Lewis Ship <hl...@gmail.com>.
There's (for the moment) two configurations that control translators.
Here's the built-in contributions, provided by TapestryModule:
/**
* Contributes the basic set of default translators:
* <ul>
* <li>Integer</li>
* <li>String</li>
* <li>Long</li>
* <li>Double</li>
* </li>
*/
public static void contributeTranslatorDefaultSource(
MappedConfiguration<Class, Translator> configuration)
{
configuration.add(Integer.class, new IntegerTranslator());
configuration.add(String.class, new StringTranslator());
configuration.add(Long.class, new LongTranslator());
configuration.add(Double.class, new DoubleTranslator());
}
/**
* Contributes the basic set of named translators:
* <ul>
* <li>integer</li>
* <li>string</li>
* <li>long</li>
* <li>double</li>
* </ul>
*/
public static void contributeTranslatorSource(
MappedConfiguration<String, Translator> configuration)
{
// Fortunately, the translators are tiny, so we don't have to worry
about the slight
// duplication between this and TranslatorDefaultSource, though it
is a pain to keep the two
// organized (perhaps they should be joined together into a single
service, where we
// identify a name and a match type).
configuration.add("integer", new IntegerTranslator());
configuration.add("string", new StringTranslator());
configuration.add("long", new LongTranslator());
configuration.add("double", new DoubleTranslator());
}
The TranslatorDefaultSource is responsible for providing a translator based
on the property type. The TranslatorSource is used (with the translator:
binding prefix) to select a translator by name.
The repetition is annoying and the two services may be merged together at
some point.
I don't think a UUID translator would be very complicated: there's a static
fromString() method.
It does make sense that there should be a default translator that leverages
the TypeCoercer to perform translations to and from strings. Perhaps
TranslatorDefaultSource is simply not needed -- scratch that: the
translators are needed to generate client-side validation JavaScript (but a
default translator would be useful, even if it could not handle client-side
validation).
On 5/22/07, Fisher, Brice A <ba...@sandia.gov> wrote:
>
> I have a bean that returns an Id as a java.util.UUID. Tapestry 5
> can't translate this into anything it can display, so I get a:
>
> ---
> java.lang.IllegalArgumentException
> No adapter from type java.util.UUID to type
> org.apache.tapestry.Translator is available (registered types are
> java.lang.Double, java.lang.Integer, java.lang.Long, java.lang.String).
> ---
>
> So, I added a Type Coercion to my AppModule to coerce UUID's to
> Strings, but that's not sufficient. Do I need to coerce UUIDs to a
> Translator (and if so, how, as it's not clear how a StringTranslator
> would be constructed)? Or is there some other interface to register a
> type with the Translator?
>
> Thanks,
> - Brice
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com