#274
  • Created on
    2010-01-05 22:46
  • Reported by
    github.importer
  • Status
    Fixed
  • Priority
    Normal (3)
  • Assigned to
    dpp
  • Milestone
    Lift 2.0-M4
  • Plan Level
    -
  • Due Date
    -

Attachments

Feature request: PCDataXmlParser flag to not convert entity references to utf-8

From
http://groups.google.com/group/liftweb/browse_thread/thread/4e33f1f2cdd02b35/352960c7974b5be3#352960c7974b5be3

> > PCDataXmlParser converts entity references to actual utf-8
> > characters. This means templates with entity references won't round-
> > trip correctly through view source, nor through localization
> > properties files / gettext files.

> Hmmm... is this worth a flag someplace to disable this behavior?

This would be extremely helpful to us, just submitting a ticket to make sure it's on the radar.

I don't mind submitting an example, given some direction on the preferred approach
User picture
  on 2010-02-06 14:51 *
By github.importer
Imported from GitHub: http://github.com/dpp/liftweb/issues/274/find
User picture
  on 2010-02-08 14:57 *
By dpp
Assigned to set to dpp
Status changed from New to Accepted
User picture
  on 2010-02-08 15:02 *
By dpp
Type set to Enhancement
Component changed from None to Utils
Milestone set to Lift 2.0-M3
User picture
  on 2010-02-11 11:41 *
By
FYI we now have a relatively hassle-free workaround for our particular gettext localization toolchain ( turns out that msgcat --properties-input doesn't handle encoded java properties correctly, but xgettext --language=JavaProperties does . . .)

I still think it'd be a useful flag, but it's not a priority for us.
User picture
  on 2010-02-26 19:47 *
By dpp
Status changed from Accepted to Invalid
Entity references are not converted to codes on output to XHTML.
User picture
  on 2010-03-03 12:57 *
By Indrajit Raychaudhuri
Milestone changed from Lift 2.0-M3 to -none-
User picture
  on 2010-03-03 22:10 *
By koeninger
Status changed from Invalid to New
I'm not sure what you mean by they are not converted - here's a reproducible case of what I'm talking about

Using a fresh archetype from 2.0-M2, no changes to anything other than index.html:

[cody@koeninger todo]$ cat src/main/webapp/index.html
<lift:surround with="default" at="content">
<p> here's an mdash: &mdash; </p>
</lift:surround>

[cody@koeninger todo]$ wget -O - cody.koeninger.org:8080 | grep mdash
--2010-03-04 03:06:24-- http://cody.koeninger.org:8080/
Resolving cody.koeninger.org... 174.143.242.144
Connecting to cody.koeninger.org|174.143.242.144|:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3159 (3.1K) [text/html]
Saving to: `STDOUT'

100%[======================================>] 3,159 --.-K/s in 0s

2010-03-04 03:06:24 (1.51 MB/s) - `-' saved [3159/3159]

<p> here's an mdash: â </p>


I would expect that last line to be

<p> here's an mdash: &mdash; </p>

Like I said, now a low priority for us, feel free to close it if it's a feature you wont add . . . but unless I'm missing something, Lift does actually behave the way I described.
User picture
  on 2010-03-16 00:55 *
By dpp
Milestone set to Lift 2.0-M4
User picture
  on 2010-03-16 14:23 *
By dpp
Status changed from New to Accepted
User picture
  on 2010-03-16 20:20 *
By dpp
Status changed from Accepted to Test
http://reviewboard.liftweb.net/r/284/
User picture
  on 2010-03-23 23:01 *
By dpp
Status changed from Test to Fixed
(In revision:629ba2515b3309dc374161564ec4a50e32ea9bc6) Closes #274. Entities are resurected as &whatever; on output

Branch: master
User picture
  on 2010-04-13 19:20 *
By dpp
Related association with ticket #471 was added