Hi Pierre,
First ones:
- is there a special order in the import instructions, especialy
between rife ones and java ones ?
The usual order is first the non JDK imports and the the JDK ones.
Also, first the wildcart imports and then the single ones. As soon as
there are 5 single ones of the same package, they become a wildcart
import.
- 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?
The reason why I removed them was that you checked for the presence
of the property manually before obtaining it. Any exception that is
still triggered after that is probably an important problem and
should at least be triggered. Swallowing exceptions is generally a
very bad idea, unless you document the reason clearly or log
something (which is usually not even a good idea for a framework). I
could find a good reason to swallow them, however if there is one,
add the appropriate comments to explain why.
Proposition: to start a wiki page on rife coding standard with the
rules I can learn from the corrections you did in my code.
Very good idea!
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?
No, not in that case, since the javadoc parser will automatically use
the Javadoc comments from the interface methods. However, if your
implementation does something special or noteworthy wrt. the
explanation of the interface, you do need to document that.
* 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.
Well in my reasoning, they could be associated with on particular
TranslatorSupport implementation, no?
If we want to decouple TranslatorSupport implementation from
ElementSupport, how to get then property specific to an element?
ElementContext.getActiveElement() ?
By injecting a property that is an implementation of
TranslatorSupport that packages all those properties together. Don't
you think that that would be cleaner and less intrusive?
* 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
Yeah, that's a worthy approach, except that in this case they are
supposed to be injectable and real properties instead of just
configuration labels.
L10N_LOCALE_PROVIDER >>> L10nLocaleProvider
l10LocaleProvider (lower cased initial)
* 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
Yes, I understand that. Is this something you needed in practice, or
do you just think that it would be nice to have? Can you give me an
example of when you needed it in a real world project?
"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())
Same question as above.
I really appreciate the work you're putting into this, thanks a lot!
Best regards,
Geert
--
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
