[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