Geert Bevin a écrit :
rarely anything is contributed to RIFE without me making changes or
consulting with other developers (for my own additions).
It was only proposition. I never hope that you take it as it :-)
* There's no need to add javadoc statements like "See [EMAIL PROTECTED]
TranslatorSupport} interface". Interface methods that are implemented
without javadocs will automatically inherit the javadocs that have
been written in the interface and have a reference towards them.
What do you mean by reference?
* Defensive markup encoding
If you remember well, I wasn't very enthusiast by this feature when
we discussed it here before. I couldn't quite put my finger on why,
but I do now. What you ask in fact is a more intelligent defensive
encoding functionality. The current implementation has been quickly
thrown together since it worked well enough for our purposes, but
evidently it does satisfy you. So instead of adding another
configuration option and imposing another syntax on users (to escape
the html tags), I think it's better to let the defensive encoding
feature detect when text is part of a tag or an entity and not encode
that. This shouldn't be terribly difficult to do.
You can detect tags with these regexp patterns:
<[a-z]+(?:\s+\w+\s*=\s*"[^"]*"*)*\s*/?>
</[a-z]+>
and entities with this regexp pattern:
&\w+;
I think that everything outside those can safely be encoded.
Maybe some special handling is needed for script tags though so that
the text in between those is always unescaped.
What if is needed some tags as litteral strings, i.e. not to be
interpreted as real tags?
Anyway, I think this should better be left for a second stage and
that the l18n is first focused on the dynamic provision of locales. I
would thus not at all create an encoder package, nor perform the
refactorings you did.
* The I18n class
This seems to be too hardcoded and linked to a SpringWeb participant.
I don't like this very much since Spring should merely be a one
possible IoC reference factory.
I put all the Spring dependencies into I18n class. Then it should be the
only part to refactor if an other container is to be used.
I haven't looked at all the interactions, but please try to leverage
the HierarchicalProperties support of RIFE that is present throughout
the whole application (from Rep, to participants, to elements):
http://rifers.org/wiki/
display/RIFE/IoC+properties+support+inside+the+repository
I did it like this in the continuation of my first proposition about
getLocales.
I'll dive asap in the HierarchicalProperties stuff.
However, I don't feel comfortable with the getTemplate
(TemplateFactory factory, String name, String encoding,
TemplateTransformer transformer) method and sibling methods that you
added. I don't particularly like the changes you performed throughout
the rest of the framework to delegate the instantiation of all engine
template types to an element. It would be best to perform the
resourcebundle addition code in the EngineTemplateInitializer class:
http://rifers.org:8088/viewrep/rifers/rife/trunk/src/framework/com/
uwyn/rife/engine/EngineTemplateInitializer.java?r=HEAD
As you see, it's possible that these templates are instantiated
without elements, so don't make the presence of an element mandatory,
things will break.
OK to use EngineTemplateInitializer. It was my first attempt ;-) I don't
remember exactly why I changed.
My goal is to get the same behavior with encoder, locales and bundles
for L10N tag in template and a direct call from an element.
Regards
Pierre
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
