Geert,
I cleaned up your patch quite a bit since you didn't really respect
the coding standard of the project. In the future, please try to
adhere to it very closely, I'm not sure I'll always be motivated to
go through all the files like this and adapt them. You also forgot
copyright statements, which I added. Please, also be careful when you
add Javadoc statements, add @since tags that refer to the next
release (1.4.1 now) and not to 1.0.
I committed everything to a separate branch since I think it needs
some more work. The branch can be found here:
https://svn.rifers.org/rife/branches/i18n
OK. I'll check each point to do better next time. I think I'll have more
questions on the Rife coding standards.
First ones:
- is there a special order in the import instructions, especialy between
rife ones and java ones ?
- in ElementSupport, you remove all the try/catch of the new methods: is
this because there is no action associated with the catch? Or because
the EngineException catching was not enough specific?
Proposition: to start a wiki page on rife coding standard with the rules
I can learn from the corrections you did in my code.
If you send me a login and password directly (not to the list), I'll
open up commit access to that branch for you.
ok
I would be interested in the opinion of other users about these
functionalities, please let us know what you think about it and if
you have any suggestions.
Here are some things that need to be done imho:
* add Javadocs on every public method and class
Even if there are implementations of interface methods?
* add a package-level Javadoc to the new i18n package and explain the
purpose and the architecture
ok
* work on you existing Javadocs, since some don't explain very well
what goes on or are still in French and not in English
oups!
* add some comments in-line your code when you use an algorithm to
explain what the purpose is of each step (the StringUtils encode
stuff), don't say what the code does, explain it in a high level
ok
* I'm not sure about the fixed property names and input names on
ElementSupport, it seems a bit hackish to me. I think it would be
better to inject an instance of TranslatorSupport. I know that RIFE's
IoC doesn't support the creation of references or invocation of
factories in-line yet in XML, but it will be added soon. Imho it
would be better to totally decouple the actual fact of having
properties or inputs from the base element support.
I put the constant values here as imo they are not associated at the
TranslatorSupport interface but at a specific implemantation, i.e.
ElementSupport.
If we want to decouple TranslatorSupport implementation from
ElementSupport, how to get then property specific to an element?
ElementContext.getActiveElement() ?
* For properties, I'm also trying to use plausible name for real
properties as much as possible. These will be injected into the
element instance if the setters are present and
setL10N_LOCALE_PROVIDER(String) doesn't look very nice.
I just used similar names and formats as what I found in Template and
Rife Config. Do you want something like
L10N_LOCALE_PROVIDER >>> L10nLocaleProvider
* I'm not entirely sure about "boolean atTheEnd, boolean withDefault"
for the addResourceBundle methods either. We're trying to reduce
boolean flags as little as possible since without reading the
Javadocs, it's impossible to know what the method call does once it's
written. Do you think it's important to have these attributes
present? If so, can you give me an example why and preferably a
better API for achieving similar functionalities?
"boolean atTheEnd" is to put the items either at the begining or at the
end of the list. "atTheEnd" at true is for the lowest priority. It's a
lowest/highest choice. May be we can use some constants like
Translator.HIGH_PRIORITY_RESOURCESBUNDLE/Translator.LOW_PRIORITY_RESOURCESBUNDLE
"boolean withDefault" : it is to ask that at least a default resource
bundle, if available, should be added. An other way would be to
provide as parameter eitheir null value or the default resourcebundle
to be used, even if it's always Localization.getResourceBundles(new
String[] {null}, getLocales())
Pierre
Best regards,
Geert
On 29-mrt-06, at 15:14, Raoul Pierre wrote:
Geert,
See herewith file.
Pierre
Hi Pierre,
can you please send the patches in a zip file, they get inline in
the message and I can't apply them.
Best regards,
Geert
On 28-mrt-06, at 15:06, Raoul Pierre wrote:
Hello,
Herewith, patch files for i18n.
To use request, user or required locales, put in config.xml the
parameter "I18N_FACTORY_IMPL" with value
"com.uwyn.rife.i18n.versatile.VersatileI18n" (by default Rife
behavior is as before).
Each element can specify a locale to be used in priority with
"L10N_REQUIRED_LANGUAGE" property (and if needed
"L10N_REQUIRED_COUNTRY")
Otherwise user locale is used if specified with
"L10N_USER_LANGUAGE" input (and if needed "L10N_USER_COUNTRY") .
If no required or user locale is specified, then the request
locales are used, if available.
Each element can have its own resource bundle: use
L10N_REQUIRED_RESOURCEBUNDLE property
Regards
Pierre
--
Geert Bevin Uwyn bvba GTalk:
[EMAIL PROTECTED]
"Use what you need" Avenue de Scailmont 34 Skype: gbevin
http://www.uwyn.com 7170 Manage, Belgium AIM: geertbevin
gbevin at uwyn dot com Tel: +32 64 84 80 03 Mobile: +32 477 302 599
PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
<i18n_patch.zip>
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
--
Geert Bevin Uwyn bvba GTalk: [EMAIL PROTECTED]
"Use what you need" Avenue de Scailmont 34 Skype: gbevin
http://www.uwyn.com 7170 Manage, Belgium AIM: geertbevin
gbevin at uwyn dot com Tel: +32 64 84 80 03 Mobile: +32 477 302 599
PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
