mitchell_neill wrote:

I'm probably talking nonsense re. SF aren't I. I guess if this should be an SMW enhancement.

Neill.

dvdgmz wrote:

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

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.

mitchell_neill wrote:

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.

mitchell_neill wrote:

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 ;)

alj62888 wrote:

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.

alex.g.muir wrote:

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.

buba.bbojang wrote:

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.

mitchell_neill wrote:

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.

alex.g.muir wrote:

(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.

alex.g.muir wrote:

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.