[TinyMCE] Jak dostosować do skryptu CMS, do API standardowego edytora, czy... Opcje

[WebCM]

Dostosowałem TinyMCE do skryptu CMS. Teraz zostaje pytanie, jak go zaimplementować, aby był kompatybilny z dotychczasowym API.

Pierwotnie zaplanowałem utworzyć możliwość podpięcia dowolnego edytora. Na razie dostosowałem tylko TinyMCE, ale muszę go wprowadzić. Czy warto stworzyć także furtkę dla innych edytorów WYSIWYG?

Administrator lub redaktor ma mieć wybór, czy chce używać standardowego (który po prostu wstawia partie HTML lub BBCode do <textarea>), czy WYSIWYG.

Aktualnie ładuję edytor tak

W kodzie PHP dołączam skrypty

[PHP] pobierz, plaintext 
$content->addScript(LANG_DIR.'edit.js');
$content->addScript('cache/emots.js');
$content->addScript('lib/editor.js');
[PHP] pobierz, plaintext 

W kodzie HTML wywołuję edytor:

Kod

var f = document.forms[0] //forma
var e = new Editor(f.txt) //utwórz edytor nad polem txt
e.emots() //dodaj emotikony pod polem <textarea>
e.protect() //ochroń przed utratą danych
f.elements[0].focus() //focus pierwszego elementu formularza

Mogę po prostu załadować edytor WYSIWYG w editor.js, ale po co w takim razie ładować standardowy edytor i jego plik językowy?

Innym wyjściem jest stworzenie mostu dla edytorów WYSIWYG. Jak to najlepiej uczynić?

Próbuję to zrobić tak, aby zachować kompatybilność z API standardowego edytora:

Kod

function Editor(o, bbcode)
{
    this.o = tinymce.add(new tinymce.Editor(o, {

        //Global settings
        dialog_type: 'modal',
        gecko_spellcheck: true,

        //Entities - UTF-8 needs only critical characters
        entities: '160,nbsp,38,amp,60,lt,62,gt',

        //Theme
        theme: 'advanced',
        theme_advanced_resizing: true,
        theme_advanced_toolbar_location: 'top',
        theme_advanced_toolbar_align: 'left',
        theme_advanced_statusbar_location: 'bottom',

        // i inne opcje

    }));
    this.o.render();
}

Editor.prototype.emots = function() {};
Editor.prototype.protect = function() {};

Czy to dobre podejście? W przeciwnym razie musiałbym osobno obsługiwać edytor standardowy i graficzny w szablonach.

No dobrze, ale jak to rozwiązać od strony serwera?

Po prostu (to tylko uproszczony przykład, aby zrozumieć sens):

[PHP] pobierz, plaintext 
if( $cfg['typ_edytora'] == 'wysiwyg' )
{
	//No dobrze, ale załadowanie tiny_mce.js należy już do skryptu portowego editor.js?
	$content->addScript('plugins/' . $cfg['nazwa_edytora'] . '/editor.js');
}
else
{
	$content->addScript(LANG_DIR.'edit.js');
	$content->addScript('cache/emots.js');
	$content->addScript('lib/editor.js');
}
[PHP] pobierz, plaintext 

Czy stworzyć bardziej ambitny i elastyczny port w PHP lub JS?

Jak najlepiej podejść do problemu?

Ten post edytował WebCM 27.05.2010, 16:40:31

[MamKonika]

No to post 2. ALE CO