Geert,
- 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.
As I'm unable to find the exception I wanted to intercepted, it 's 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.
Well in my reasoning, they could be associated with on particular
TranslatorSupport implementation, no?
Imo ElementSupport is a specific implementation, and there is no reason
that all implementations work like it. But may be it's a little too
flexible.
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?
So we need to wait for a full rife ioc ...
"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?
It's used in ElementSupport.decorateTemplate. Usually, new bundles are
added at the top priority level. But here we need to put them at the
lowest priority level.
It's also used in AbstractTemplate.addResourceBundle.
I don't really see how to replace/remove it. May be a better name as
"topPriority" (and inversion of true/false value).
"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.
Here it's only to avoid to create a default bundle list before to know
if this list is needed.
This boolean parameter can be replaced by the default bundle list
itself. But imo, there is no advantage with such a parameter. It'd
better to keep only 2 parameters, String[] baseNames and boolean atTheEnd.
Pierre
_______________________________________________
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
