No, it's used when you do getHtmlTemplate from within your
element. Using getXhtmlTemplate gives you an ENGINEXHTML type.
Sorry I was not clear enough. The point is neither about html or
xhtml file suffix nor about ENGINEHTML or ENGINEXHTML instances:
it's always EncoderHtml which is used.
Yes, which provides exactly the functionality that the enginexhtml
need too.
What do you mean with the dtd?
Even in files with html suffixe, it can be xhtml code, e.g. in src/
templates/crud/common/blueprint_admin.html, you have:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd">
Ok, but that doesn't really matter, does it? Both engine types behave
the same except for resolving the template name with a file name
extension.
- AbstractTemplate.evaluateL10nTags uses
EncoderHtml.encodeDefensive and not EncoderHtml.encodeDefensive
to convert string,
that is StringUtils.encodeHtmlDefensive
- this last method doesn't convert "<", "&", ">", "'" and """
So, for html files with xhtml dtd and for xhtml files, we can
have trouble when any of the above characters is present in a
key's value, e.g. double quote used in an attribute's value:
then the end of the value is not displayed.
I'm not fully following, can you give an example?
For exemples:
1/ put some < character inside element body like: Take x<p and
then..., the tag will be
2/ a buttom wich must display text with quotation inside as: Liste
des "canailles", the tag will be
3/ if simple quote is used for an attribut and the text is:
S'inscrire, then the tag will be
4/ with value as "Rire & pleurer"
Ok, yeah, of course I know about all this. One of the reasons that
encodeDefensive has been created is to make the life of people that
don't know anything about html entity encoding better. You an then
simply provide html editing capabilities to your customer, without
them needed to encode all the entities before it's considered valid.
For property files, it's a different story, I agree.
Is there any reason against to used EncoderHtml.encodeDefensive
in all the cases.
Yes, if you want to make sure that no html tags or entities can
be provided at all through form fields.
OK
I never used such possibilities. I put only "pure" text in
properties files: anybody can translate them without knowing
anything in codage.
Is the choice only between:
- to be able to provide html tags ans entities from properties files
- to be able to use "<", "&", ">", "'" and """ caracters for
attribute or element values.
May be it's possible to do both of them:
- for any element or template, to give the choice between with or
without html tags/entities capabilities
- even in the case "without html tags/entities", to be able to use
them with escaping, like
summary-legend = XHTML Transitional 1.0\\<br /\\>Fragment
body-help = \\<div class=\\"form_help\\"\\>Vous pouvez saisir ici
le texte complet de la "nouvelle". Seul \
du texte XHTML valide est acceptable.\
\</div\\>
I'm not so sure about this. You'll still have to educate people that
they have to escape these character with a custom RIFE method. In my
opinion, it's much better for them to know how to escape the
characterd that encodeDefensive doesn't handle in a standard xhtml
way. At least they already know it correctly. Also, check out the
frequency. How often do you add <>&"' to text. It's actually just
really once in a while. When you have xhtml enabled properties,
you'll have a lot more characters for the tags. So imho this custom
escaping might actually be more work.
Best regards,
Geert
--
Geert Bevin Uwyn bvba
"Use what you need" Avenue de Scailmont 34
http://www.uwyn.com 7170 Manage, Belgium
gbevin[remove] at uwyn dot com Tel +32 64 84 80 03
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://www.uwyn.com/mailman/listinfo/rife-users