Why not handle it in the editor ? [Re: [fpc-devel] fpdoc content syntax suggestion]

[Martin]

On 09/07/2010 19:21, Sergei Gorelkin wrote:
>
> I'd suggest the following:
>
> 1) XML stays :-)
> 2) The fpdoc is modified in a way that, after parsing the initial XML, 
> every text node
> within <short> or <descr> elements is additionally parsed with another 
> parser.
> 3) The "another parser" does its job, placing its results into a DOM 
> fragment.
> 4) The original text node is replaced with the resulting subtree.
>
> 5) Choose the new format so it does not use '<' and '&' extensively, 
> because these will have to be escaped.
>
> This way, it will be possible to mix 'old' and 'new' syntax within a 
> single document to any extent, and we won't need to touch the backends 
> at all.

I don't quite see why we need to change the storage format? Most of the 
discussion is about issues applying to editing the content.
Especially since a new content format together with the need of reading 
old files too, will always leead to the need of supporting 2 file 
formats => that IMHO is the worst solution.

You can have an editor that displays and edits the content in any format 
you like and validates it at the same time. But it saves it in the 
current format after all.

so you edit:    "[b]key[/b] < 1"
and the editor saves:   "<b>key</b> < 1"

You need the translator anyway, for dealing with old files, so  you may 
rather put the translator into the editor.
that allows to offer different editors for different likes of different 
people.
  \bkey\B < 1
  *key* < 1
  true wysiwyg
   ....

Martin