Czy warto, używając wbudowanego administratora Django dla przyzwoitego projektu?

Question

Nie używam Django zbyt długo, ale mam zamiar rozpocząć całkiem spory projekt. Zawsze denerwuję się, używając całkiem nowych frameworków (nowych dla mnie) w dużych projektach, ponieważ wcześniej byłem spalony. Jestem jednak całkiem pewny w Django ... to ostatecznie będzie projekt, który sprawi, że przeskoczę z mojego rodzimego frameworka PHP do popularnej frameworki Pythona. (yay!)

W każdym razie, moje pytanie brzmi, czy wbudowany administrator Django jest na tyle solidny, aby używać go do pełnowartościowego interfejsu skierowanego do klienta (klienci będą go używać, nie ja). Widzę, że jest dość konfigurowalny, ale zastanawiam się, czy można go rozszerzyć na tyle, aby obsłużyć różne niestandardowe przypadki. Nie mam żadnych konkretnych przykładów, odkąd jeszcze się nie zacząłem.

Czy ktoś użył administratora Django do całkiem spersonalizowanych interfejsów, z których korzystają użytkownicy niebędący programistami? Czy było warto? Czy wolałbyś raczej stworzyć własny interfejs administratora specjalnie dla strony?

Aby wyjaśnić, użytkownicy byliby całkowicie nie-tech.

Answer 1

Jeśli dobrze rozumiem, chcesz użyć administratora django dla wszystkich użytkowników, aby umożliwić im aktualizację witryny.
Jeśli to prawda, myślę, że można go używać w sposób odmienny od tego, co było jego głównym celem, jak można dostać się z Django book (podkreślenie jest moje):

Dla pewnej klasy Web strony, interfejs administratora jest niezbędną częścią infrastruktury.Jest to internetowy interfejs, ograniczony do zaufanych administratorów strony, który umożliwia usuwanie, edytowanie i usuwanie zawartości witryny.

Jeśli użytkownicy muszą aktualizować zawartość (np., Powiedzmy, dodawanie nowego artykułu), może to być OK.
Ale jeśli chcesz go użyć do dowolnej interakcji z witryną, to myślę, że wygoda użytkownika nie będzie tak dobra.

Myślę, że bardzo dobrym przykładem tego, w jaki sposób można użyć administratora, a kiedy nie należy go używać, jest ReviewBoard: tam większość działań użytkownika jest obsługiwana bezpośrednio przez witrynę, a tylko konfiguracja i zarządzanie są wtedy obsługiwane za pomocą administratora.

Ostatecznie jest to kwestia użyteczności użyteczności. Jeśli uważasz, że jest w porządku, aby twoja aplikacja miała inną sekcję do zarządzania dodatkiem do strony, to strona administratora Django może być oszczędna w czasie rzeczywistym. We wszystkich innych przypadkach może lepiej zainwestować więcej czasu.

Answer 2

Moja firma zbudowała CMS na Django, który obsługuje wiele zadań (płaskie strony, blogi, sekcje przeznaczone tylko dla członków, importowanie i parsowanie danych z zewnętrznych stron takich jak youtube i flickr, listy mailingowe, albumy piosenek i teksty piosenek dla artystów itp.) i do tej pory nadal korzystamy z wbudowanego administratora. Mamy kilku bardzo nietechnicznych klientów używających go regularnie.

Możesz dość daleko posunąć się w dostosowywaniu go za pomocą plików admin.py, gdy naprawdę się do niego dostaniesz. Jedyne, co dodaliśmy, to tinyMCE i Filebrowser, aby ułatwić te aspekty użytkownikom końcowym.

Powiem, że pracujemy nad modułem galerii, w którym ma być potrzebować niestandardowego administratora. Poza tym byłem bardzo szczęśliwy i pod wrażeniem tego, jak elastyczny i wszechstronny może być administrator Django. Jest to równie przyjazne dla użytkownika, jak można to sobie wyobrazić.

Answer 3

To zależy. Administrator da ci spory margines, ponieważ różne grupy użytkowników mają dostęp do różnych tabel, a jeśli dasz im dostęp do różnych interfejsów administracyjnych, możesz nawet udostępnić im różne zestawy kolumn dostępnych w tabelach. Jednak administrator nie jest tak skonfigurowany, aby pozwolić ci ograniczyć dostęp do poziomu wiersza użytkowników w zależności od poziomu autoryzacji. Po wprowadzeniu ich do tabeli mogą wprowadzać zmiany do dowolnego dostępnego dla nich obiektu.

Można dostosować widżety jednak chcesz przez instacji typy widgetów (choć wbudowana filter_horizontal i raw_id_admin są niezbędne i zrobić to proste zadanie dla niektórych typów danych!)

Więc myślę, że to zależy od tego co masz na myśli przez klientów. Jeśli masz na myśli ludzi, którzy wynajęli Cię do napisania strony internetowej (myślę, że nazwałbym ich klientami, a nie klientami), to istnieje duża szansa, że ​​administrator będzie ci odpowiadał. Jeśli masz na myśli użytkowników końcowych witryny, trzymałbym się ręcznie wykonanych formularzy django.

Answer 4

Ogólnie widzę administratora Django jako interfejs do wykonywania żmudnych zadań wstawiania i edycji. Nie obawiam się więc w dużym stopniu go dostosować (nawet jeśli oznacza to podklasowanie wewnętrznych obiektów Django i przekazywanie ich z powrotem do interfejsu administratora w czasie wykonywania), ale należy pamiętać, że będzie to wymagało przeczytania źródła Django (na szczęście nie jest to bardzo trudno to zrobić).

Więc dla mnie, dyskryminator używania go lub nie jest „insert, delete, update” koncepcji tej mapy bardzo dobrze do tabel bazy danych, a nie ilość użytkowników wiedzy technicznej, kwotę Ufam użytkowników lub wielkość projektu .