Poprzedni wpis (Zagadka rozwiązana) | Następny wpis (Introducing django-confirmation)
Code reuse that isn't
Django jest fantastyczne m.in. w tym, że istnieje masa podłączalnych aplikacji, które w sposób wystarczająco generyczny realizują często spotykane zadania, jak np. django-registration do rejestrowania użytkowników, czy django-tagging do etykietowania obiektów. Część z tych aplikacji jest naprawdę wysokiej jakości, w dodatku łatwo konfigurowalnych i możliwych do dopasowania w dość szerokim zakresie. Są jednak takie, które dobrze się zapowiadają od dłuższego czasu, jednak na tym się kończy. Co bardziej zaskakujące, wszystkie te potencjalnie użyteczne aplikacje pochodzą z projektu Pinax.
W jednym z projektów potrzebuję dodać funkcję powiadamiania użytkowników o wystąpieniu pewnych zdarzeń. Jest aplikacja django-notification, ale w stanie obecnym nie nadaje się do wykorzystania poza Pinaxem (lub w sposób jakkolwiek różny od tego, jak to jest robione w Pinaksie). Zgłoszone są problemy z tym związane, jednak zostały odłożone na lepsze czasy. Będę musiał wziąć kod django-notification i wzorując się na nim napisać swoją własną aplikacyjkę, bo na te lepsze czasy się nie doczekam.
Inny przykład. Niedawno potrzebowałem dodać do pewnego projektu możliwość tworzenia obiektów przez niezalogowanych użytkowników — wymagane jest wtedy podanie adresu email i potwierdzenie dodania obiektu przez standardowe kliknięcie w przesłany link. Znalazłem aplikację django-email-confirmation, która robi coś podobnego, ale nie nadaje się do potwierdzania jakichkolwiek innych obiektów, niż jej własne (a ja potrzebowałem zastosować ten mechanizm do 3-4 różnych klas obiektów). Trzeba było napisać własną, na szczęście okazało się to dość proste, przyjmując django-email-confirmation za wzór.
I to samo mam za każdym razem, gdy trafiam na aplikację, która mogłaby mi się przydać, a pochodzi z Pinaxa — bez zakodowania własnego rozwiązania bazującego na tym kodzie się nie obejdzie. Rozumiem, że Pinax jest rozwijany w normalny dla OS/FS sposób, to znaczy w czasie wolnym i nikt nie bierze za to pieniędzy, ale skoro tak to wygląda, to jaki jest sens wydzielać aplikacje jako niby reużywalne, skoro tak naprawdę nie dają się użyć nigdzie poza aplikacjami typu Pinaxa i ich reużywalność to głęboki mit?
Etykiety: django free software / open source programowanie python
Komentarze (4)
#2 Marcin Kaszyński skomentował(-a) 14 listopada 2008 o 14:59
To prawda. Pinax wygląda bardzo fajnie, jeśli się go postawi i używa w całości, ale wybranie z niego części aplikacji i dostosowanie ich do istniejącego serwisu to rzeźba.
Niestety -- reusability jest trudne i drogie. A tworzenie grupy aplikacji, które mają być reusable, pod jednym szyldem jako "integrated" dodatkowo sprawę mocno utrudnia.
To wszystko nie zmienia jednak faktu, że zdecydowanie warto się istniejącym aplikacjom dla Django przyglądać. Wiele z nich potrafi oszczędzić sporo czasu.
#3 riklaunim skomentował(-a) 17 listopada 2008 o 13:50
W Django powstają raczej specyficzne aplikacje - ktoś ma konkretne potrzeby i pisze taką aplikację. Nieco inne potrzeby zazwyczaj skutkują w potrzebie napisania nieco innej aplikacji - różniącej się w większym stopniu od pierwszej...
#4 jarek skomentował(-a) 18 listopada 2008 o 12:32
I wszystko cacy, nie mam nic przeciwko pisaniu aplikacji do własnych potrzeb. Tylko po co wprowadzać lud w błąd, że aplikacja jest "reużywalna", skoro nie jest?
Skomentujesz?
* oznacza pole wymagane



#1 j4rek skomentował(-a) 14 listopada 2008 o 13:48
Zawsze przerażał mnie ten buzz wokół Django i haseł które mowią o reusability i DRY.
A jeszcze bardziej przerażały mnie osoby które próbowały mi wcisnąć w projekcie jakieś komponenty pt."to już zostało napisane" a po kolejnych życzeniach klienta musiałem przebudowywać kod tego prawie że od nowa aby to było rozszerzalne pod jego kątem.
Scary and stupid. Na enterprise będziemy musieli jeszcze trochę poczekać.