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 <[EMAIL PROTECTED]> 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
