Unify the code to preprocess and posprocess the html

[Alfonso Martínez de Lizarrondo]

In a way similar to this patch: ​https://sourceforge.net/tracker/index.php?func=detail&aid=1434698&group_id=75348&atid=543655
it will unify some redundant code and avoid bugs like this one: ​https://sourceforge.net/tracker/index.php?func=detail&aid=1573191&group_id=75348&atid=543653

[Frederico Caldeira Knabben]

Alfonso, please hold on for a while with this one. This is another important feature I've been thinking about. It is quite important for some developments we need to do in the near future (MediaWiki integration).

I'm taking this comment to introduce you Johnny Egeland. He has just joined our team. He did a great job by creating a cleanup mechanism for the output generated by FCKeditor to make if 100% compliant to the XHTML Transitional DTD specifications. His first task in the project is rewriting the XHTML processor to incorporate the (very customizable) cleanup system.

Part of the post-processing is the XHTML processing, in the default configuration. But I want to make it customizable, because many times developers don't want to output XHTML, but would prefer other formats, like BBCode, or even the MediaWiki tagging system.

I've just created two new components?: "Core: Pre/Post Processor" and "Core: XHTML Processor". I think we should all work together to write down their specifications. I'll try to post the first drafts soon.

For all important core features, I would always like to have the specifications before we start coding. In this way all we are able to give our bits to it, and come in an agreement.

[Alfonso Martínez de Lizarrondo]

My idea was quite simple, it doesn't involve any change in the transformation from DOM to XHTML, just set up two functions that (specially the first one) will be called whenever an string is going to be inserted (SetXHTML or InsertHTML) and then have also a single point to revert those changes. An non-updated version would look like this:

//makes it easier to change the way that the Html is preprocessed before it is displayed.
//gets the html and process it (protecting special parts that the browser would alter
//automatically 
FCK.PreprocessHTML = function( sHtml )
{
	sHtml = FCKConfig.ProtectedSource.Protect( sHtml ) ;
	sHtml = FCK.ProtectEvents( sHtml ) ;
	sHtml = FCK.ProtectUrls( sHtml ) ;

	return sHtml ;
}

//Before giving back the html we make sure that any
//processing it's done
// This is important if the user switches to source mode
FCK.PostProcessHTML = function( sHtml ) 
{
	sHtml = FCKConfig.ProtectedSource.Revert( sHtml ) ;

	return sHtml ;
}

In the original patch I also added an explicit option so a developer can add his own functions in the chain, but it isn't neccesary.

But I don't have any hurry so I'll wait for the new system to understand how it works and what it can do.

[Frederico Caldeira Knabben]

I've just created a Wiki page for it: Components/DataProcessor?.

I've called it Data Processor, instead of Pre/Post Processor. This is just an initial proposal. Comments on it is highly appreciated.

Alfonso... if you feel the proposed implementation overrides the patches you have nominated in this report, please feel free to resolve it as "wontfix".

[Alfonso Martínez de Lizarrondo]

Yes, that proposal could take care of the current problem where the SetHtml and InsertHtml apply different protection to the code.