Changes between Initial Version and Version 1 of Ticket #1244


Ignore:
Timestamp:
07/26/11 17:03:13 (3 years ago)
Author:
dread
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1244 – Description

    initial v1  
    1 When you edit a package in the web form, in the notes field, CKAN favours {{{\r\n}}} over other EOL characters. (The Markdown processor respects both EOLs when displaying the field, putting each line in a <p> tag.) 
    2  
    3 The problem arises if you have a package created via the API, which may have other expressions of EOL e.g. just {{{\n}}}. These EOLs disappear when you edit a package in the web form. Thus when you subsequently save the package, the {{{\n}}} character is removed, even though you might not intend this, and the notes field is displayed all on one line. 
     1When you edit a package in the web form, if the notes field had {{{\n}}} as the End Of Line symbol, it gets lost when you preview or save the package, and the notes field is displayed all on one line. 
    42 
    53This can be seen when editing annakarenina (as created by 'paster create-test-data'). The diff shows for example: 
    … …  
    1917 
    2018It's not clear what we should do about it. We could standardise on \n or \r\n when the form submission comes in. Do different browsers on different platforms do different things with EOLs? 
     19 
     20== Analysis == 
     21 
     22Displaying the package: the Markdown processor respects both EOLs when displaying the field, putting each line in a <p> tag. 
     23 
     24Creating the package edit form: placed into <textfield>.  
     25 
     26Browser displaying package edit form: <textfield> displays \n and \r\n as EOL. But \n\n gets compressed to one EOL. But on submission, both are returned as \r\n. 
     27 
     28Receiving the edited package: Somewhere along the line the EOL gets converted to \n\n.