Last modified: 2014-02-12 23:37:57 UTC
Hi. I am entering this after seeing a question posted on the mailing list about having tables within SF text fields. There is an extension called PipeEscape that allows for pipe characters in parser function arguments avoid being interpreted as an argument delimiter. This works great if manually used in SF text fields. Would it be an idea to have this code actually incorporated into SF forms? In this way you can have tables, galleries etc in SF text area fields without the user having to manually insert (or even being aware of) the PipeEscape extension markup. Cheers Neill.
I'm probably talking nonsense re. SF aren't I. I guess if this should be an SMW enhancement. Neill.
It seems me a useful feature. Maybe the fields can have a 'pipeescape' parameter: {{{field|MyField|pipeescape=true}}} Another approach could be having parameters to put content in the field value before and after the content entered by the user: {{{field|MyField|before=|after=}}} In this case we can put: {{{field|MyField|before={{#!:|after=}} }}} resulting: {{MyTemplate |MyField={{#!: Content introduced by the user }} }} and perhaps this could be useful for other cases. But I don't know if is something difficult to implement. - dvdgmz.
No, actually this is a SF problem as well. It is all very well wrapping the text field in the template with the pipe escape, but next time you edit with form the entered text will get busted if a pipe char is present. So you have to have the pipe escape parser call actually in the field meaning the users have to be aware of it and how to use it. This is not ideal. So, the SF parser would benefit from pipe escaping text fields. Cheers Neill.
dvdgmz - both of those syntax ideas you suggest sound useful. Especially the second one. I'm always afraid to make the SF template-parsing code any more complicated than it already is, but in theory, I think that's a good idea.
The before and after idea would be really useful. I could see that being used for all sorts of things :) A pipescape parameter might be simpler to implement though ;)
I have properties that hold full text in it's values and has to handle any character. This is not just a pretty formatting issue; one single character that is inaccurate to what the user intends will break my process. I vote for this to be resolved.
Yes I agree.. seems like it would be useful.. perhaps a simple fix would just be to convert the | [ ] into the html equivalent on upload or when saved through a form? The html equivalent representations work but not on upload of xml.
I agree with Alex. It would be great if the html equivalent representations works on xml upload... Anyway, getting it fixed without making it more complex than it is, is more important. So I vote for it.
Ordinary users can't be expected to "double-escape" the relevant characters, by replacing "{" with "[", and so on. Surely this can be sorted with a small code tweak? Thanks.
(In reply to comment #9) > Ordinary users can't be expected to "double-escape" the relevant characters, > by > replacing "{" with "[", and so on. > > Surely this can be sorted with a small code tweak? > > Thanks. Yeah I'd agree with that the average user that will be editing the forms manually shouldn't have to know how to do this. Which php files would need to be edited to add this logic? I was thinking just to add the feature on my side here.
Just to clarify, the double-escaping is only needed if you're doing an XML import - due, I assume, to some sort of bug in Special:Import.
It's probably a normal feature of an xml parser to convert the html entities to ascii. Inserting in the interface one does not need to double escape.
