part of the "Title" clipped by Roma, in a somewhat sneaky fashion

[TEITechnicalCouncil]

When I input the following into the "Title" window in the "Customize" tab in Roma:

TEI Lite customization for Twardowski's "O czynnościach i wytworach"

and press "save", the part enclosed in quotes vanishes, so the saved XML only contains

<title>TEI Lite customization for Twardowski's </title>

However, one can be easily mislead into thinking that everything is good (like when you have filled the "Description" window, and you click on "Save" and move on the e.g. the "Modules" or "Save.." tabs), because the full string is still displayed in the upper right corner, This is illustrated by the attached screenshot.

Original comment by: @bansp

[TEITechnicalCouncil]

That information appears to be "saved" in the DOM input element where it was typed, in the form of its @value attribute, but that process screws up, resulting in:

<input type="text" system""="" the="" of="" value="This is a test " size="53" name="title"...>

for input of:

This is a test "of the system". The bug must be somewhere in the JavaScript.

Original comment by: @martindholmes

[TEITechnicalCouncil]

I've had a quick look through the code, and this is a possible source of error I see:

tei-roma/parser/parser.php appears to generate output by performing a series of search-and-replace operations on a template. That would operate on this part of the templates/customizeCustomization.tem template file:

<td class="formfield"><input type="text" name="title"
 size="53" value="{title}"></td>

If it's not cautious about quotes (and it doesn't seem to be), it would end up creating output that closes the @value attribute prematurely and dumps the rest into the element creating invalid content, which the browser would attempt to parse into spurious attributes.

The idea of storing text node content (which might even have elements in it, never mind quotes) in an HTML attribute value is very fragile, but it's the way the whole thing is built. It could be made more robust by some careful escaping of data values on the way in, but it'll take a bit of work.

Original comment by: @martindholmes

[TEITechnicalCouncil]

i think Martin's analysis is spot on, and I am not surprised that Roma has some problems like this.

perhaps you can find a PHP programmer to contribute some fixes, Piotr?

Original comment by: @sebastianrahtz

[TEITechnicalCouncil]

• assigned_to: Hugh A. Cayless

Original comment by: @hcayless

[TEITechnicalCouncil]

• assigned_to: Hugh A. Cayless --> Martin Holmes

Original comment by: @hcayless

[TEITechnicalCouncil]

Martin will have a go at this.

Original comment by: @hcayless

[TEITechnicalCouncil]

I've committed a fix for this. I've done a certain amount of testing locally, but until this is uploaded to wherever it is that Roma runs, I'm going to leave the bug open.

TEIC/Roma-Antiqua@18cc86d

Original comment by: @martindholmes

[TEITechnicalCouncil]

This issue was originally assigned to SF user: martindholmes
Current user is: martindholmes

[martindholmes]

After some confusion figuring out where Roma actually is on tei-c (there are lots of copies), I've deployed the new version and asked Ian to give us a symlink at http://www.tei-c.org/Roma-4.18/ so that we can test it out. If it tests OK, we can change the existing symlink to make it live. Then we can adopt and document a standard approach to updating Roma on the server.

[martindholmes]

Council confirms this is the way to proceed, and suggests moving this bug to the TEIC/Roma repo.

[peterstadler]

Already closed per TEIC/Roma-Antiqua#8