--=REKLAMA=--
--=REKLAMA=--
Ta strona wymaga przetłumaczenia lub jest w trakcie tłumaczenia! Pomoc jest mile widziana. Ostatnio edytowane przez Zwiastun (dyskusja. Data edycji: Sat, 07 Dec 2013 22:05:43 +0000
 |
{{{tekst}}} |
W pierwszych trzech częściach, mamy opracowany komponent MVC, który pobiera dane z tabeli w bazie danych. Obecnie nie ma sposobu, aby dodać do bazy danych, z wyjątkiem zrobienia tego ręcznie, korzystając z innego narzędzia. W następnej części tego podręcznika będziemy rozwijać sekcjie administratora naszego komponentu, który pozwoli na zarządzanie wpisami w bazie danych.
Ta część, Cześć 4 - Tworzenie administracyjnego interfejsu, będzie to tylko artykuł bez nowego kodu źródłowego do naszego komponentu, ale opisujący pewne podstawowe informacje oraz szczegółowe wyjaśnienia wzorca MVC. Ten pośredni rozdział nie jest wymagany do ukończenia Hello komponentu, więc jeśli myślisz, że rozumiesz podstawy mozesz kontynuować Projektowanie komponentu według wzorca Model-Widok-Kontroler - Część 5 - Podstawowy framework zaplecza.
W rozwiązaniu front-end (w sekcji witryny, części 1,2 i 3) stworzyliśmy pierwszą część naszego komponentu. Rozwiązanie front-end jest oparte na default Controllers, Views i Templates ,które ze soba współpracuja. Teraz stworzymy sekcjie Back-end administracji dla naszego komponentu Hello(w części 5 i 6) - trzeba będzie opracować cały kod, który zarządza aplikacjią od strony Back-end.
Joomla! jest systemem zarządzania treścią. interfejs jest używany do przedstawiania użytkownikom treści i pozwala niektórym zalogowanym użytkownikom do manipulowania zawartością. back-end jest odpowiedzialna za administrowanie farmeworkiem (struktura/ zarządzania / sterowania / utrzymanie). Ten podział (front-end) zawartość witryny oraz (back-end) administracja jest podstawowym aspektem Joomla!.
Z treści pliku XML naszego przykładu było już oczywiste, że nie będzie części administracji:
<?xml version="1.0" encoding="utf-8"?> ... <administration> <!-- Administration Menu Section --> <menu>Hello World!</menu> <!-- Administration Main File Copy Section --> <files folder="admin"> <filename>hello.php</filename> <filename>index.html</filename> <filename>install.sql</filename> <filename>uninstall.sql</filename> </files> </administration> ...
Jedynie pliki sql były przeznaczone i tylko w trakcie instalacji, a dwa pozostałe pliki nie zawierają żadnych treści oprócz generowania pustej strony. Dostęp do systemu plików (np. na serwerze lokalnym). pozwala przeglądać katalogi, po zainstalowaniu komponentu com_hello front-end. Można zauważyć, że nasze Hello zainstalował się w dwóch katalogach:
<root>/components/com_hello <root>/administrator/components/com_hello
Te dwa katalogi to kolejno cześć odpowiedzialna za wyświetlanie witryny i administracji. Gdy gość lub zarejestrowany użytkownik wchodzi na stronę domyślnie wywoływany jest plik z katalogu:
<root>/index.php
Administratorzy będą musieli się zalogować, i po zalogowaniu wejdą na witryne za pośrednictwem:
<root>/administrator/index.php
Z różnych punktów dostępu, łatwo jest zrozumieć, że w konfiguracji w sekcji administratora nazewnictwo nie ma zależności z sekcja witryny. Choć wzorzec MVC stosuje się również do sekcji administratora oznacza to, że identyczne kontrolery, widoki, modele i nazewnictwa mogą (a czasami muszą) być użyty w sekcji witryny.
W celu ułatwienia prezentacji będziemy używać przykładu. Biblioteka posiada główną funkcję wypożyczania książek dla zarejestrowanych użytkowników. Wiec potrzebne są trzy tabele:
Zawartość będzie bardzo prosta. Użytkownicy rozpoznawani przez Id i Name. Książki[books] identyfikowane przez identyfikator[Id] i tytuł[Title] książki oraz relation zawiera zarówno identyfikatory[IdU - id użytkownika]&[IdB - id książki] i daty[Date] wypożyczenia.
Przykładem jest starannie dobrany i pomoże w wyjaśnieniu struktury Joomla! bardziej szczegółowo. Po stronie administracyjnej naszego Hello komponentu struktura tabel nie jest złożona sklada sie tylko z jednej tabeli do zarządzania. Po wytłumaczeniu tej części toturiala bedziesz potrafił w łatwy sposób zrozumieć to w następnych częśćiach.
W tym przykładzie zakładamy, że działania administracyjne (add, edit, delete) są zadaniami(np. task=add), które mają być wykonywane przez administratora. Dla użytkownika to tylko udostepniony interfejs widok tabeli Relation informacje("kiedy muszę oddac książki?"). Ten przykład pokazuje całą listę i ignoruje wszystkie prywatne dane, które mogą być wyswietlone, tylko zarejestrowanemu użytkownikowi który widzi swoje książki. (See: JUser object for making user deviations in template module).
Nasze frontend Hello component, udostepnia domyślny widok używany w front-end. Poprzez odpowiednie zapytanie SQL za pomocą opcji "LEFT JOIN" lączy tabele, w celu uzyskania czytelnej listy książek z odpowiadającymi im datami.
Alice | One flew over ... | 12-aug-2009 Alice | Celeb talk | 12-aug-2009 Mark | Joomla! | 15-aug-2009
W odniesieniu do tej części administracji ważne jest, aby zrozumieć, że mamy jeden domyślny i trzy dodatkowe widoki, każdy kontroluje trzy zadania:
Główny kontroler sekcji admin wymaga wyróżnienia pomiędzy poszczególnymi Dodaje, Zapisuje lub Usuwa jesli to wymagane. Ma za zadanie opiekę nad wywolywaniem sub-kontrolerów dla każdego widoku do obsługi konkretnych zadań.
<root>/administrator/controller.php <root>/administrator/controllers/users.php <root>/administrator/controllers/books.php <root>/administrator/controllers/relation.php
Kontroler jest ważnym elementem wzorca projektowego MVC. Nie tylko dba o uruchamianie odpowiednich zadań, jest również inicjatorem instancji modelu o tej samej nazwie jak również odpowiedzialny za stworzenie widoku i sposobu prezentacji danych dla tego widoku. Dlatego w pełni zasługuje na nazwe controller.
Wewnątrz kontrolera powinno się odróżniać zadania między aktywnym zadaniem(na przykład: user kliknął edit z menu) a zadaniem które wynika z tego zadania (na przykład skutkiem edycji są wystawione dane).
Typowy kontroler działa tak:
funkcja < aktywne zadanie >() // <-- edit, add delete { JRequest::setVar( 'view', '[<componentname> | users | books | relation ]' ); JRequest::setVar( 'layout', 'default' ); // <-- Ustawienie domyślnego szablonu, ale wewnątrz // szablonu mogą być załadowane inne szablony // w razie potrzeby. parent::display(); } funkcja < wynikające zadanie >() // <-- save, remove { $model = $this->getModel('[<componentname> | users | books | relation ]'); if(!$model->action() ) { // <-- Action może być delete() lub store() $msg = JText::_( 'Error: Could not perform action' ); } else { $msg = JText::_( 'Action executed' ); } $this->setRedirect( 'index.php?option=<componentname>', $msg ); }
Kontroler dba aby wszystkie zadania zostały uruchomione przez odpowiedni kontroler. Po wykonaniu zadania wynikającego przekierowuje do głownego pliku i co za tym idzie uruchamia główny kontroler z domyślnym widokiem i w tym wypadku wyświetla wiadomość. Aktywacja zadania wywoła nowy widok z formularzem do wyswietlenia.
Określenie formularz w widoku może wywołać pewne zdziwienie, ale nasze przykłady są zbyt proste. W odniesieniu do ogólnego zrozumienia i spójności powinny być głównie domyślne. W złożonych widokach wiele formularzy może zostać określone w jednym widoku.
Kontrolery współdziałają z ich jednakowo nazwanymi modelami.W widoku frontend Model był wykorzystywany tylko do pobierania danych.back-end model plików nie tylko jest odpowiedzialne za dostarczenie danych do odbiorcy, ale również troszczy się o zadania zainicjowane przez kontroler.Dobry model zawiera wszystkie wymagane działania w jednej tabeli bazy danych.
<root>/administrator/models/<componentname>.php <root>/administrator/models/users.php <root>/administrator/models/books.php <root>/administrator/models/relation.php
Oddzielne widoki są oczywiście również wymagane. Dla widoków i kolejnych formularzy nie sa wymagane konwencje nazewnictwa (za linkowanie widoku odpowiada kontroler).W poniższej liście zadań administracyjnych są identyfikowane jako podzbiór dla różnych widoków.Ten wybór jest całkowicie przypadkowy i być może nawet nie -- logiczny ale to nie ma znaczenia dla wytłumaczenia. Tylko na przykład dodałem również inny widok, usuń widok, który mógłby zostać użyty dla wszystkich zadań administracyjnych pytając "Are you sure" display.
<root>/administrator/views/<componentname>/view.html.php + .../tmpl/default.php <root>/administrator/views/users/view.html.php + .../tmpl/default.php <root>/administrator/views/books/view.html.php + .../tmpl/default.php <root>/administrator/views/relation/view.html.php + .../tmpl/default.php <root>/administrator/views/delete/view.html.php + .../tmpl/default.php
Note: W ogóle dobrze jest zachować jedną formę per view, ponieważ view.html.php jeszcze dostarcza zawartości. Pewne podstawowe elementy można włączyć, wyłączyći, ale jeśli takie rozumowanie staje się zbyt skomplikowane, można zacząć zastanawiać się nad podziałem widoku.
Note: Sharing template parts amongst the different views (for uniform layouting of headers and titles of your component) can be done using the PHP include / require;. There is one slight problem ... how to make the logical reference? In my modules I have a collector bin for general to use sniplets. Because it involved the views and forms I put this general bin in the views directory. The variable $pathToGeneralView needs to be defined somewhere in the first lines of your file and you have to make sure that the logical reference path is correct (the '..'s). In the following example the files marked with a '*' use the following code:
./com_compname/views/general/navigate.header.php <-- sniplet code for the header ./com_compname/views/general/navigate.footer.php <-- sniplet code for the footer ./com_compname/views/mngtable1/view.html.php ./com_compname/views/mngtable1/tmpl/default.php * ./com_compname/views/mngtable2/view.html.php ./com_compname/views/mngtable2/tmpl/default.php *
$pathToGeneralView = strchr(dirname(__FILE__), dirname($_SERVER['SCRIPT_NAME'])); $pathToGeneralView = str_replace(dirname($_SERVER['SCRIPT_NAME']),'.',$pathToGeneralView ); $pathToGeneralView = $pathToGeneralView . "/../../general/"; <-- returning path from current position. ... <?php require_once $pathToGeneralView . 'navigation.header.php'; ?> <P>Do something <?php require_once $pathToGeneralView . 'navigation.footer.php'; ?>
To samo inny sposób:
$pathToGeneralView = JPATH_COMPONENT_ADMINISTRATOR. "/views/general/"; <-- will return 'path/Joomla/administrator/components/com_example/views/general/' ... <?php require_once $pathToGeneralView . 'navigation.header.php'; ?> <P>Do something <?php require_once $pathToGeneralView . 'navigation.footer.php'; ?>
Uwaga: Nadanie formie innej nazwy zamiast default jest oczywiście przydatne, gdy mamy wiele różnych widoków. Ponadto, wiele form default może utrudnić określenie kontekstu. Z drugiej strony, view.html.php nie może być zmieniona, a jeden jest zawsze zmuszony posiadać w nazwie nazwę katalogu.
Wszystko jest na miejscu:
Pozostaje jedeno wielkie pytanie: Jak z nich korzystać!
Trzy parametry są obowiązkowe do wykonania zadania w Joomla!:
Te trzy parametry są niemal samo wyjaśniające;). Ze strony option przy tworzeniu komponentu sprawa jest prosta, zawsze przypisać do niej nazwę komponentu. Dla komponentu rozwoj jest stały, oczywiście silnik Joomla! ma więcej opcji niż tylko komponenty.
Parametrami controller i task można manipulować jak tylko chcesz.
Patrząc na uproszczony obraz MVC Joomla! logiczny strumień interakcji wygląda w następujący sposób:
W HTML, są dwa sposoby komunikowania się z Joomla!:
Pamiętaj o zadaniach aktywujących i zadaniach wynikających wspomniano o nich wcześniej? Większość zadań aktywujących jest inicjowana przez link. W przypadku np. Biblioteki przegląd sekcji witryny można skopiować do panelu administracyjnego. Ten widok domyślny zostanie rozszerzony i każda komórka stanie się linkiem do edycji danego elementu bazy danych.
Na przykładzie Biblioteki, szablon PHP bez pętli zawierać będzie następujący kod:
$link = JRoute::_( 'index.php?option=com_library&controller=users&task=edit&cid='. $row->idu ); echo "<td><a href=\"".$link."\">$row->name</a></td>"; $link = JRoute::_( 'index.php?option=com_library&controller=books&task=edit&cid='. $row->idb ); echo "<td><a href=\"".$link."\">$row->title</a></td>"; $link = JRoute::_( 'index.php?option=com_library&controller=relation&task=edit&cid='. $row->idr ); echo "<td><a href=\"".$link."\">$row->date</a></td>";
W każdej komórce można kliknąć trzy linki z obowiązkowymi parametrami do manipulacji Joomla!, która je zidentyfikuje. Ponadto istnieje jeden parametr do obsługi prawidłowego wskazania w kontrolerze zadania(cid). Parametry te są oddzielone '&'. Nie wolno używać spacji w zmiennych, niektóre przegladarki mogą pominąć taki parametr. Po pętli, wszystkie wpisy będzie można kliknąć i uruchamiają one odpowiedni kontroler właściwy wiersz id w powiązanej tabeli.
[Alice] | [One flew over ...] | [12-aug-2009] [Alice] | [Celeb talk] | [12-aug-2009] [Mark] | [Joomla!] | [15-aug-2009]
Po zainicjowaniu aktywnego zadania, widok formularza wejściowego może być skutkiem. Fragment kodu poniżej może być wynikiem klikniecia pierwszej komórki w widoku domyślnym, po kliknieciu do edycji ([Alicja]: cid = 3).
<form action="index.php" method="post"> <input type="text" name="username" id="username" size="32" maxlength="250" value="<?php echo $this->user->name;?>" /> <input type="submit" name="SubmitButton" value="Save" /> <input type="hidden" name="option" value="com_library" /> // <-- mandatory <input type="hidden" name="controller" value="hello" /> // <-- mandatory <input type="hidden" name="task" value="save" /> // <-- mandatory <input type="hidden" name="id" value="<?php echo $this->user->id; ?>" /> // <-- user parameter, index in database for [Alice] </form>
Trzy obowiązkowe parametry są wprowadzane jako ukryte w formularzu. Parametry ukryte nie są wyświetlane w żaden sposób, ale zostaną dodane do wysyłania poprzez dane POST.
Wskazówka: Podczas debugowania tego formularza, zastąpić w form tag method="post" tymczasowo na method="get". Wszystkie parametry pojawią się w adresie URL przeglądarki. Jeśli moduł działa cofnąć tę zmianę. Jednym z powodów nie pokazywania wszystkich parametrów w URL jest unikniecie motywowania ludzi do manipulowania tymi danymi w URL przeglądarki. Drugi powód jest bardziej techniczny, że metody post (tj. method="post") może zawierać bardziej (złożone) dane.
Uwaga: W niektórych rozwiniętych modułach można zauważyć, że deweloperzy dodaja parametr również do view. To jest błąd, tylko kontroler(y) powinny dbać o parametry view i form.
Użycie trzech parametrów obowiązkowych i różnych punktów dostępu, zostanie wyjaśnione. Zróbmy coś z tą wiedzą i rozszerzmy Hello komponent do działu administracji w kolejnych artykułach tego tutoriala.