Geert,
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.
The main thing that bothers me is that it imposes a bunch of standard
property names for something as basic and generic as ElementSupport.
It doesn't feel right to me.
OK, I put them with all the specific methods in a
ElementTranslatorSupport class.
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 ...
Actually, no. You can already use it now and provide the
TranslatorSupport instance from a participant. Full IoC reference
factory support isn't required for you to implement it. It's might
just be handy to have for people that declare their site structures
in XML and want to also declare an IoC reference in there. Using
Java, Groovy and Janino for the site structure doesn't required this
support at all.
OK. The above class is a first step in this direction. It's now possible
to use it by default, and if needed to specify a other TranslatorSupport
for each element. I'll commit this as soon I have finish to complete the
comments.
Possibly next step: start with the participant stuff but as i see the
thing, it'll be to intanciate directly a Translator.
"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).
I understood that, I'm more looking for a real-world use case that
warrants this feature. I can see why it might be theoretically
interesting, but doubt that it warrants the API complexity increase
in practice.
"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.
Same remark as above.
I propose a compromise: I remove "withDefault" and keep a "withTopPriority"
Regards
Pierre
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
