I agree that localization better not be confused w/ indirection.
Still, I need indirection because it helps me centralize setting things and helps avoid much duplication. And as we all know duplication is the enemy of maintainability. I was hoping we'd somehow agree to address this need (I'm not hung up on the implementation details ;-).
The solution you propose, namely that I write my own font converter does not scale well. After all, if I want to code this stuff directly, then I can do away w/ the XML file altogether.
Regards,
-Babak.
On 10/11/05, List for Users of Carlsbad Cubes' Technologies and Products <Forum@carlsbadcubes.com
> wrote:
After talking with a couple Swixml developers offline, I don't think we should
implement general attribute indirection like is was proposed in this thread.
I don't want to see localization to be confused or mixed with using 'indirect
attributes values', basically trying to use localizaion as a string
pre-processor.
If you want to flag attribute values that require localization with an '@'
character, you are free to do so, by prefixing your keys with an @ character
too.
If you want to <i>'sprinkled font="SansSerif--12" liberally everywhere across
the file'</i>, I suggest you simply overwrite the FontConverter.
Changing the Parsers behavior in respect to which attr. are considered for
Localization is as simple as adding or removing attribute names to/from the
public vector: Parser.LOCALIZED_ATTRIBUTES
/**
* Localiced Attributes
*/
public static final Vector LOCALIZED_ATTRIBUTES = new Vector();
Converter classes are extreemly simple pieces of code and should be replaced
(unregistered) or overwritten, if this kind of speacial functionality is
needed.
BTW, the Class parameter is used somewhere, I think in the PrimitiveConverter.
Moreover, the converter model was built with the idea that developers would
implement there own converters, we wanted to make them as flex. as
possible and
therefore added the Class param...
--
Wolf Paulus
707.202.3937
[EMAIL PROTECTED]
C a r l s b a d C u b e s
Dedicated to Excellence
Quoting List for Users of Carlsbad Cubes' Technologies and Products
<Forum@carlsbadcubes.com >:
>>
>> I assume you would like to change the Converter.convert(Class, Attribute,
>> Localizer) to
>> Converter.convert(Class, Attribute, Object localizedAttributeValue),
>> correct?
>>
>
> Actually, I was thinking the change would look more like
>
> Converter.convert(Class, Attribute)
>
> The reason why I thought this way is that the Parser only deals w/ strings;
> and the Converters' job is to turn those strings into other kinds of objects.
>
> The Parser (as demo-ed unclearly in the diff I submitted) just examines
> the attribute value, and if that value needs to be "translated", it just
> replaces the translated value with the original:
>
>
> < String key = attr.getValue();
> < String value = getChainedLocalizer().getString(key);
> < if (!key.equals(value))
> < attr.setValue(value);
>
>
> -Babak.
>
> P.S. On a separate note--but while we're on the topic-- I'm not sure
> I understand what role the "Class" parameter in Converter.convert () plays?
> After all, by the time we pick the right Converter, we already know
> what type it will be converting to... (It's not like the caller can
> *tell* the
> implementation which type to convert to, and I can't find a single place
> where a Converter implementation uses this parameter...)
>
> _______________________________________________
> Forum mailing list
> Forum@carlsbadcubes.com
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>
_______________________________________________
Forum mailing list
Forum@carlsbadcubes.com
http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
_______________________________________________ Forum mailing list Forum@carlsbadcubes.com http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
