[dev] [EN] Rich text implementation

Goffi goffi at goffi.org
Jeu 7 Nov 16:08:52 CET 2013


G'day all

sorry for this message in english only...

I have commited backend part for managing rich syntaxes, here are some 
comments:

- first of all, database has changed, you need to manually update it. 
Open the database (usually "sqlite3 ~/.sat/sat.db" should do it) and 
enter "ALTER TABLE history ADD COLUMN extra BLOB;". I guess that we will 
need an automatic update tool soon, specialy now that SąT enterred 
several major GNU/Linux distributions

- parameters are now updated in case of an already existing parameter 
name, so I renamed memory.importParam to memory.updateParams

- the extra data dictionary is now saved in database, and sent with 
getHistory return value. Frontends have been updated.

- as I had to managed deferred with newMessage trigger, I have added a 
post_treat argument to the trigger: plugins can add callbacks to this 
deferred to add treatments (this is done here to add rich syntax to the 
extra data).

- I have added lxml as a dependency

now comments about the rich syntax:

- syntaxes are managed by misc_text_syntaxes plugin

- I have choosed XHTML (utf-8) as main language. To add a syntax, you 
need two methods: one for new_syntax => XHTML, and one for XHTML => 
new_syntax. This allow to reuse easily the tons of text conversion 
tools, and to easily convert from one language to another.

- when you add a syntax, by default the conversion methods are threaded 
so you can easily use blocking code, but this can be deactivated with 
OPT_NO_THREAD flag.

- an added syntax is automatically added to the Composition/Syntax 
parameter, except if the OPT_HIDDEN flag is set.

- a convert method allow to convert from any managed syntax to any 
other one, by default the resulting code is cleaned to avoid anything 
malicious, this can be deactivated with the safe attribute.

- so far, the cleaning is done using lxml's cleaning method, but the 
*styles are not cleaned yet*, this can be potentially dangerous. So I'm 
waiting to clean styles before updating online Libervia demo.

- when rich text is present, it's always put in a "xhtml" key in the 
extra data dictionary, so the frontends only have to manage XHTML, which 
is most of time already done in graphical toolkits. It can anyway use 
the convert bridge method if it want to use another syntax.

- external images are included in the XHTML, which can lead to pricavy 
concerns (downloading external image can show the online presence or 
proove that a message has been opened). It's the role of the frontend to 
not display the external file except if user explicitly ask for it. I'm 
planing to add a parameter to manage this. This is actually true for all 
external files, not only images (but normally, no other external files 
will appear in the resulting XHTML)

- so far, only Libervia show rich text, and only for instant messaging. 
It will change soon :)

Cheers
Goffi



Plus d'informations sur la liste de diffusion dev