Bug 42551 - improve editor modularization
improve editor modularization
Status: NEW
Product: Lenya
Classification: Unclassified
Component: Miscellaneous
Trunk
Other other
: P2 enhancement
: 2.0.1
Assigned To: Lenya Developers
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2007-05-30 14:08 UTC by J
Modified: 2007-07-16 02:22 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description J 2007-05-30 14:08:12 UTC
we should improve the modularization of editors - no editor quirks should remain
in doctype modules or core xslts. to that end, each editor must implement its
own pre- and post-processing pipelines. pipeline views can be used to implement
that without requiring hooks in the publication sitemap.
in addition to the editor-specific post-processing of documents, richard frovarp
made a suggestion that i like quite a bit:

>> well, then just put the fck stuff there, too. but we should make a 
>> huge mental note that each editor module should do their own 
>> pre-processing and cleanup in the future...
>>
> 
> This is post-processing. I do see that kupu does its own pre-processing, 
> which I'm going to be copying part of for fck. What is needed is for the 
> editors to do their own post-processing and include a global 
> post-processing file, such as clean-xhtml.xsl. All of the editor don't 
> have anything to lose converting i to em for example. No need to 
> replicate that step 4 or more times.

i.e. each editor should include a global (per doctype? needs some thought) xslt.
if a user wants to set a global XHTML policy, like discouraging <i> in favour of
<em> or <strong> in favor of <b>, s/he can declare it just once and be done with it.