Pisząc systemy CMS, możemy się spotkać z powtarzającym się wymaganiem: ma być edytor WYSIWYG do tekstu. Widywałem aplikacje Django, w których główny admin był budowany na tym, co oferuje framework, a drugi - pisany ręcznie z edytorem WYSIWYG do większych tekstów. Zawsze jakieś rozwiązanie, ale da się lepiej. Jak?

Przede wszystkim: gałąź newforms-admin

Jeśli istnieje ktoś, kto jeszcze jej nie używa, niech zapozna się z jej opisem. W skrócie - bardziej elastyczny i podatny na własną rozbudowę admin budowany na bazie newforms.

Instalacja front-endu

Wybrałem FCKeditor, ze względu na duże możliwości i prostotę w implementacji, ale sposób działa dla dowolnie innego edytora. Należy ściągnąć paczkę i wrzucić ją tak, aby katalog z całością był dostępny pod ścieżką /fckeditor/. Tak jest domyślnie, ale nikt nam nie przeszkadza, by to zmienić, jeśli chcemy inaczej.

Drobna modyfikacja skryptu integrującego z Pythonem

Twórcy FCKeditora byli na tyle mili, by udostępniać go razem z pythonową klasą. Kopiujemy fckeditor.py do wybranego przez nas katalogu i przycinamy funkcje IsCompatible do takiej postaci:

def IsCompatible(self):
    return True

Widget dla newforms

Kod z Django snippets:

from django.newforms.widgets import Widget
from django.utils.safestring import mark_safe
from django.utils.encoding import force_unicode
import myapp.core.fckeditor as fck
# ........
class FCKeditor(Widget):
   def __init__(self, attrs=None):
	   if attrs is not None:
		   self.attrs = attrs.copy()
	   else:
		   self.attrs = {}

	   self.__widget = fck.FCKeditor("FCKeditor1")
	   super(FCKeditor, self).__init__(attrs)

	   self.setAtters(self.attrs)

   def setAtters(self, attrs):
	   if attrs is None:
		   return

	   if 'basepath' in attrs:
		   self.__widget.BasePath = attrs['basepath']

	   if 'width' in attrs:
		   self.__widget.Width = attrs['width']

	   if 'height' in attrs:
		   self.__widget.Height = attrs['height']

	   if 'toolbar' in attrs:
		   self.__widget.ToolbarSet = attrs['toolbar']

   def render(self, name, value, attrs=None):
	   if value is None: value = ''
	   value = force_unicode(value)

	   self.__widget.InstanceName = name
	   self.__widget.Value = value
	   self.setAtters(attrs)

	   final_attrs = self.build_attrs(attrs, name=name)
	   return mark_safe(self.__widget.CreateHtml())

Podczepienie widgetu do modelu

W moim przypadku jest to model Clip, zmieniam formularz dla textfield-u description:

class ClipOptions(admin.ModelAdmin):
	# .........
	
	def formfield_for_dbfield(self, db_field, **kwargs):
		if db_field.name == 'description':
			kwargs['widget'] = FCKeditor
		return super(ClipOptions,self).formfield_for_dbfield(db_field,**kwargs)

# ...
global_admin = admin.AdminSite()
global_admin.register(Clip, ClipOptions)

Gotowe

Oto jak wygląda w realnej aplikacji: Zmie0144 klip | Administracja stron0105 Django

Komentarze: Skocz na dół, na górę

  1. FCKEdit = fail. Nie dało rady TinyMCE? :-)

  2. Osobiście jestem za tym, żeby zbanować wszystkie tego typu edytory. Ktoś, kto zajmuje się edycją treści powinien przejść jednodniowe (tak naprawdę półgodzinne…) szkolenie z HTML-a i dokumentacji CSS-a dla danego sajtu.

  3. A potem będziesz miał co 5 minut telefon od Pani Jadzi, że jej się coś nie wyświetla tak jak chce.

  4. Dokładnie. I właśnie dlatego napisałem tego posta :).

  5. Ja też jestem przeciw edytorom WYSIWYG na stronach www. Z jednej strony html nie jest aż tak trudny, żeby ktoś nie mógł się go nauczyć. Z drugiej jednak strony tak samo nie każdy musi umieć obsługiwać Photoshopa, czy Gimpa. Dlatego w każdym edytorze ważne jest dla mnie, aby była możliwość ręcznego pisania kodu – wtedy będzie i wilk syty i owca cała :)

  6. Witam, przydatny fragment, dodałbym jeszcze jedną linijkę, żeby zachować defaultowe widgety.

    if db_field.name == ‘description’:
    kwargs[‘widget’] = FCKeditor
    return db_field.formfield(**kwargs)
    else:
    return super(ClipOptions,self).formfield_for_dbfield(db_field,**kwargs)

    pozdrawiam,

  7. A co z uploadem np. grafiki?

  8. Integracja przeglądarki plików i uploadu grafiki to piekło w przypadku takich edytorów. Aczkolwiek nie ma problemu w tym, by zajrzeć do dokumentacji edytora i „podpiąć” dodatkowe funkcjonalności, których back-end napiszemy w Django.

    Ja jednak jestem najbardziej za tym, by zostawić ludziom możliwość pogrubiania, pochylania, podkreślania tekstu oraz definiowania list i nagłówków. Żadnych tabel, grafik, kolorów itp. Z doświadczenia wiem, że ludzie są pozbawieni gustu, i jak tylko mogą to, za przeproszeniem, nasrają kolorków, stylów i grafik ile wlezie. Dla dobra ich wizerunku i Waszego portfolio – unikajcie takich sytuacji.

Dodaj komentarz na temat

Zanim skomentujesz...

W komentarzach działają znaczniki Textile.
Zastrzegam sobie prawo do edycji Twojego komentarza tylko i wyłącznie w celach estetycznych (naprawienie źle wstawionego kodu, itp). Nie zmieniam ich treści, ortografii, interpunkcji. Jeśli odczuwasz potrzebę edycji swojego komentarza, skontaktuj się ze mną, a zdziałamy co trzeba.