System Eliminacji Studentów, który Jest był już Aktywny [dla tych, co się nie wyspali: SESJA] oraz tygodniowy wyjazd na narty skutecznie uniemożliwił mi wyprodukowanie czegokolwiek na blogu, za co przepraszam wszystkich najmocniej i obiecuję poprawę. Ze względu na to, że aktualnie jestem na etapie powrotu do “normalności” [czytaj: nie miałem komputera od ponad tygodnia] dzisiaj chciałbym poruszyć nieco lżejszy i “bardziej abstrakcyjny” [czytaj: nie będzie kodu] temat. Liczę na Waszą aktywność w komentarzach, ponieważ “wyjątkowo” cały wpis zamiast przedstawiać mój punkt widzenia będzie tylko lekko sugerował pewne możliwości. Tym razem jest on ukierunkowany na zapoznanie się z Waszą opinią. Mam nadzieję, że dzięki swoistej “burzy mózgów” dojdziemy do ciekawych wniosków. Zapraszam do lektury.

Wstęp.

W czym problem? Otóż: chciałbym rozważyć różne sposoby tworzenia / integracji paneli administracyjnych w stronach / aplikacjach internetowych. Ze swojej strony opisuję dwie opcje, jakie nasunęły mi się po krótkim przemyśleniu całej sprawy, ale mam nadzieję, że razem damy radę wymyślić więcej. ;] Zyskiem z rozwiązania tej “niejasności” będzie “jedynie” świadomość dobrze ugruntowanego i przemyślanego rozwiązania, jednak wydaje mi się, że jest ona warta uwagi.

Wariant I: Oddzielna aplikacja.

Pierwszym wariantem tworzenia panelu administracyjnego jest oczywiście oddzielny skrypt. Każdy, kto po raz pierwszy zetknął się z samym problemem stworzenia “zarządzalnej” strony internetowej prawdopodobnie wpadł na pomysł zrobienia oddzielnej aplikacji, która oferowałaby możliwość interakcji z tymi samymi danymi, co strona zarządzana. Jest to rozwiązanie stosunkowo proste, które stosowałem do tej pory bez większego zastanowienia nad sensem / celem / optymalnością i - co ważne - sprawdzało się znakomicie. Szczególnie na tle ostatnich wpisów dotyczących frameworka symfony, który posiada bardzo fajne narzędzie “Admin Generator” podejście to wydaje się najmniej pracochłonne i najbardziej optymalne z punktu widzenia ewentualnej rozbudowy serwisu - wszelkie operacje na panelu nie mają wpływu na działanie samej strony. Ważne jest też to, że raz napisany panel administracyjny możemy wykorzystać w innym projekcie, co dodatkowo oszczędza pracy naszym palcom [głowie też, ale w mniejszym stopniu, bo połączenia między odpowiednimi neuronami już powstały ;]]. Wypunktujmy zatem [, dla tych, co nie lubią czytać ;]]:
  • Możliwość automatycznego wygenerowania panelu przez narzędzia takie jak Admin Generator frameworka symfony.
  • Łatwość rozbudowy.
  • Niezależność od strony zarządzanej.
  • Możliwość przeniesienia gotowego produktu do innego projektu.

Wariant II: Zintegrowany z aplikacją.

Innym sposobem na rozwiązanie problemu “zarządzalności” może być integracja funkcjonalności panelu w stronie zarządzanej. Możemy to zrobić na wiele sposobów, najbardziej optymalny [moim zdaniem] wydaje się ten polegający na wyświetleniu dodatkowych opcji zalogowanym użytkownikom o odpowiednim poziomie uprawnień. W ten sposób użytkowanie strony, szczególnie, jeśli dostęp do elementów “zaawansowanych” mają osoby spoza głównej grupy twórców [np. moderatorzy i inne grupy uprzywilejowane, w zależności od charakteru projektu] staje się o wiele prostsze - nie zmuszamy użytkowników do ponownej nauki ułożenia elementów i ogólnej logiki działania aplikacji [zakładam, że panel administracyjny w pierwszym wariancie to aplikacja oderwana od “rzeczywistości” samej strony zarządzanej - przede wszystkim inny layout]. Jest to rozwiązanie nieco trudniejsze i wymagające większego nakładu pracy, może też powodować trudności z wprowadzaniem istotnych aktualizacji, ze względu na to, że logika działania obu elementów [panelu i strony] jest ze sobą ściśle powiązana. Podsumowując:
  • Łatwiejsze korzystanie z funkcjonalności panelu.
  • Bardziej zwarta struktura całości.

Podsumowanie.

Szczerze mówiąc od pewnego czasu jestem “kuszony” przez ten drugi wariant, szczególnie ze względu na bardzo ładnie wyglądającą interakcję pomiędzy oboma elementami całego projektu, ale kiedy biorę pod uwagę czas pracy i ewentualne późniejsze problemy z rozbudową, decyduję się jednak na wykonanie oddzielnego skryptu [wariant pierwszy].

Chciałbym jednak poznać Wasze zdanie na ten temat, szczególnie miło byłoby, gdybyście opisali konkretne rozwiązania z Waszego doświadczenia i skutki, jakie pociągnął za sobą określony wybór. Jeśli masz inny pomysł na rozwiązanie sprawy - także będę wdzięczny za podzielenie się spostrzeżeniami.