Hi Geoff,
thanks a lot for your example. This was exactly what I was searching
for.
I am not trying to achieve anything special with the FieldTranslator,
only tried to upgrade my application from 5.0.14 to 5.0.15. I just
wanted to make my Translator work again, and the error messages I got
told me that tapestry is looking for some FieldTranslator instead of
Translator now, and was not able to convert the Translator I provided
to a FieldTranslator (because of some missing configuration on my side).
It seems that in 5.0.14, you didn't need to register your Translators
(your method contributeTranslatorSource() in AppModule), but starting
from 5.0.15, it is necessary to do so. After I added the
contributeTranslatorSource() method to my AppModule, everything works
as before.
Well, almost, but I'll start a new thread for this.
Thanks again, Geoff!
Best Regards,
Christoph
On Oct 26, 2008, at 03:20 , Geoff Callender wrote:
What are you trying to achieve with FieldTranslator that Translator
doesn't already do? I guess what I'm is whether the following
example needs more work? http://202.177.217.122:8080/jumpstart/examples/input/creatingtranslators1
Cheers,
Geoff
On 26/10/2008, at 6:41 AM, Christoph Jäger wrote:
Ok, lets try to make our Translator also implement FieldTranslator.
FieldTranslator defines 4 methods:
1. Class<T> getType()
2. T parse(String input)
3. void render(MarkupWriter writer)
4. String toClient(T value)
1 is already implemented in Translator, for 2 we can call the
already existing parseClient() method, 4 is already implemented.
The only problem is 3: the API documentation says: "Invokes
Translator.render(Field, String,
MarkupWriter,org.apache.tapestry5.services.FormSupport)". So now
our implementation needs to know about the Field and FormSupport,
and a MessageFormatter. Where do you get these from in your
implementation?
There is a FieldTranslatorImpl class, which takes all of these
objects as parameters for the constructor. Maybe use this instead
of making your Translator also implement FieldTranslator? But as
there is a class like this, I think it should be automatically
instantiated when a FieldTranslator is needed and only a Translator
is available. Am I missing something here?
Best Regards,
Christoph
On Oct 25, 2008, at 16:13 , Joachim Van der Auwera wrote:
Well, I now just assure all my Translators are also
FieldTranslators and vice versa.
Kind egards,
Joachim
Christoph Jäger wrote:
Hi,
I just stumbled upon the same problem when updating from 5.0.14
to 5.0.15. There must be a way that Tapestry automatically
creates the FieldTranslator if a Translator is specified for a
field. All the information should be there. As I see it, apart
from the Translator, the FieldTranslator needs the Field, a
MessageFormatter and a FormSupport instance to do its work. I
can't believe we have to "manually" pick up all of these objects
and create a FieldTranslator (a separate one for each field in a
form). Looking at how Tapestry automatically creates / converts /
coerces lots of other useful stuff, I am almost sure there are
some magic configuration entries to enable automatic creation of
FieldTranslators (given a Translator), we just need to find them.
Best Regards,
Christoph
On Oct 8, 2008, at 19:25 , Joachim Van der Auwera wrote:
Howard Lewis Ship wrote:
A FieldTranslator is a wrapper around a Translator that is
configured
for a specific Field component.
Thanks.
Should these not be created automatically?
This has caused me major headaches for migrating to 5.0.15, I
had to change all my translators, assure they also implement
FieldTranslator and replace all translate="translate:string" to
a (custom) StringTranslator which implements both Translator and
FieldTranslator.
Kind regards,
Joachim
On Wed, Oct 8, 2008 at 5:40 AM, Joachim Van der Auwera <[EMAIL PROTECTED]
> wrote:
And when should which be used?
I am getting coercing errors trying to convert between the
two, but it is
unclear to me why there is a difference (the interfaces look
very similar).
Joachim
--
Joachim Van der Auwera
PROGS bvba, progs.be
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Joachim Van der Auwera
PROGS bvba, progs.be
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Christoph Jäger
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Joachim Van der Auwera
PROGS bvba, progs.be
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Christoph Jäger
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Christoph Jäger
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
