Thanks Bryan,
Yes it seems this is some functionality that has been victim of some
other architectural concept.
This is confusing and disappointing to me - I see it as a key facility
that should be provided by the framework since one of the key tasks (you
could argue "the key task") of web applications is to convert objects
into strings and back again.
I see the role of formatters and translators intricately linked -
otherwise there is certain code repetition and therefore maintenance
issues. Also, constantly defining getter methods in components to make
global formatters available is hardly a good approach, and no better
than extending a 'BaseComponent' to access these properties.
This could be solved with the old style "service" binding prefix which
is also gone from the implementation.
If no one can tell me what existing tapestry concept I'm missing I may
spend some time seeing if I can write some code to get this going.
Step one would be to create an object structure that makes it easy to
define an object that implements both Translator and Formatter.
Step two would be to create a binding prefix to supply the appropriate
Translator/Formatter object to components, which would be registered in
the binding prefix by name.
p.
On 23/12/2010 12:31 AM, Bryan Lewis wrote:
I don't have a great answer, but since you asked again...
I had a similar surprise a year ago because I was expecting things to work
as they did in Tap4:
http://www.mail-archive.com/users@tapestry.apache.org/msg39593.html
But someone (Thiago probably) pointed out that it wasn't so hard to specify
the desired translator on each instance of a textfield:
<t:textfield value="bigDecimalValue" translate="prop:currencyTranslator"/>
My base Page class has a getCurrencyTranslator() method that merely does
"return new CurrencyTranslator();".
Since then, I wrote an Insert component (reusing a Tap4 name we were
accustomed to) that allows me to pass my translators to an output string,
something like your "reuse as formatter" objective. I can say:
<t:insert value="bigDecimalValue" translate="currencyTranslator"/>
and reuse my translator's formatting code.
On Tue, Dec 21, 2010 at 9:29 PM, Paul Stanton<p...@mapshed.com.au> wrote:
anyone?
On 5/12/2010 10:59 AM, Paul Stanton wrote:
Hi Thiago,
If I want a way to make commonly used translators (and formatters)
available to every component I can:
1. create a service and inject it into every component class and mark it a
property
2. create my own binding prefix
am i missing something ? I would expect this to be easier, ie a way to
contribute entries to the 'translate' binding prefix...
also, the other part of my question/suggestion is that it would be nice to
be able to re-use translators as formatters.
I don't see why this wouldn't be possible since translators do the job of
formatters.
p.
On 5/12/2010 4:18 AM, Thiago H. de Paula Figueiredo wrote:
On Sat, 04 Dec 2010 12:13:02 -0200, Paul Stanton<p...@mapshed.com.au>
wrote:
I also can't find any documentation regarding the config of Translators
... ?
The contribution for TranslatorSource defines the default translator. If
you want to use another one, just pass it to the translator parameter.
You'll probably use the prop binding. Something like this:
<t:textfield ... t:translator="prop:fancyTranslator" />
public Translator getFancyTranslator() {
return ...
}
If you use alternative translators a lot, you can create a binding for
that, avoiding the methods to provide them.
You can't use a Translator directly as the format parameter to the Output
component because it expects a java.text.Format instance. I prefer to do the
formatting in the page or component class instead of using this component.
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
