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

Reply via email to