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.


Standardowy edytor ładuję tak:

W kodzie PHP dołączam skrypty:

$content->addScript(LANG_DIR.'edit.js');
$content->addScript('cache/emots.js');
$content->addScript('lib/editor.js');

Edytor wywołuję w szablonach, np. tak:

//formularz
var f = document.forms[0]

//utwórz edytor nad polem txt
var e = new Editor(f.txt)

//dodaj emotikony pod polem <textarea>
e.emots()

//ochroń przed utratą danych
e.protect()

//focus pierwszego elementu formularza
f.elements[0].focus()

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:

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

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

// i inne opcje, trochę ich jest

}));
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 przykład, aby zrozumieć sens):

if( $cfg['typ_edytora'] == 'wysiwyg' )
{
$content->addScript(...);
}
else
{
$content->addScript(LANG_DIR.'edit.js');
$content->addScript('cache/emots.js');
$content->addScript('lib/editor.js');
}

Nie chce zmieniać nazwy pliku tiny_mce.js na inną, a trzeba też gdzieś
zmieścić opcje konfiguracyjne (jak w poprzednim przykładzie). Czy
stworzyć bardziej ambitny i elastyczny port w PHP lub JS? Jakąś klasę,
czy co? Czy po prostu zrobić furtkę dla WYSIWYG w standardowym
edytorze lib/editor.js (on ładowałby TinyMCE, kiedy trzeba)?

Jak najlepiej podejść do problemu?

do góry

Dnia Fri, 28 May 2010 04:40:26 -0700 (PDT), WebCM napisał(a):

> 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?

Nie. Narobisz się i nigdy tego nie wykorzystasz, bo wszyscy przyzwyczają
się do domyślnego. Później zaś będziesz musiał wspierać i aktualizować
wszystkie.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

> Nie. Narobisz się i nigdy tego nie wykorzystasz, bo wszyscy
> przyzwyczają się do domyślnego. Później zaś będziesz musiał
> wspierać i aktualizować wszystkie.

Niby TAK, ale może ktoś będzie chciał podpiąć inny edytor, bo TinyMCE
mu nie odpowiada. Z drugiej strony czy ewentualni twórcy wtyczek
poprawnie go dostosują i będą aktualizować? Jeśli nie, rzeczywiście to
spadnie na mnie.

Załóżmy, że dodaję wyłącznie obsługę TinyMCE. Mimo to i tak na 90%
będzie obsługiwany jako rozszerzenie.

Jakie macie pomysły na poprawną (działającą), ale elastyczną
implementację edytora WYSIWYG w skrypcie CMS? Czy warto zachować
kompatybilność z API standardowego edytora (tzn. istniejącego od
początku)?

Szczegółowo problem z przykładami kodów opisałem tutaj:
http://tinymce.moxiecode.com/punbb/viewtopic.php?id=
21687

do góry

Dnia Fri, 28 May 2010 11:01:56 -0700 (PDT), WebCM napisał(a):

>> Nie. Narobisz się i nigdy tego nie wykorzystasz, bo wszyscy
>> przyzwyczają się do domyślnego. Później zaś będziesz musiał
>> wspierać i aktualizować wszystkie.
>
> Niby TAK, ale może ktoś będzie chciał podpiąć inny edytor, bo TinyMCE
> mu nie odpowiada.

Wierzysz w to? Dla innego edytora, różniącego się detalami, będzie się
komuś chciało grzebać w czyimś kodzie, dostosowywać go i jeszcze później
pilnować aktualizacji? Raczej nie tworzysz drugiej Joomli, gdzie może komuś
z dziesiątek tysięcy użytkowników przyjdzie ochota na taką zabawę.

> Jakie macie pomysły na poprawną (działającą), ale elastyczną
> implementację edytora WYSIWYG w skrypcie CMS? Czy warto zachować
> kompatybilność z API standardowego edytora (tzn. istniejącego od
> początku)?

IMO tworzysz zbędne problemy. Przy włączonym WYSIWYG-u dodawaj kod
inicjalizujący skrypt z parametrami typu identyfikatory textarea, lista
wtyczek, ścieżki i tyle.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry