Tekst źródłowy strony Projektowanie komponentu według wzorca Model-Widok-Kontroler - Część 4 - Tworzenie interfejsu administracyjnego

{{DoPrzetłumaczenia}}{{SpisPoPrawej}}{{wersja/poradnik|1.5}}
{{ambox
| type  = notice
| image = notice
| text  = This {{thingamabob}} has been divided into three sections, two new articles are added. Especially this page needs a review
<small>(August 2009)</small>}}
== Wprowadzenie ==

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.

== Site / Admin ==
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!.

=== Entrance points ===
Z treści pliku XML naszego przykładu było już oczywiste, że nie będzie części administracji:
<source lang="xml"><?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>
  ...
</source>
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.

== MVC pattern interaction ==
[[Grafika:joomla_MVC.png|frameless|right]]W [[Developing a Model-View-Controller Component - Part 1]] Na rysuneku po prawej stronie został przedstawiony wzorzec ''Model-View-Controller Component tutorial''. Teraz użyjemy tego rysunku do wyjaśnienia, jak podejmowane są decyzje o tym, co ma być wyświetlone i jak tym manipulować.

=== Example roll-out ===
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:
* users
* books
* relation

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.

[[Grafika:Library Example.png|400px|frameless|center]]

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.

=== Mapping a Joomla! MVC component from the example ===
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'': [http://api.joomla.org/Joomla-Framework/User/JUser.html 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:
* <Component name default view>
* User administration
** Add
** Change
** Delete
* Book administration
** Add
** Change
** Delete
* Relation administration
** Add
** Change
** Delete

==== Controllers ====
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:
<source lang="php">
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 );
}
</source>
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.

==== Models ====
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

==== Views ====
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 <code>include / require;</code>. 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 *

<source lang=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'; ?>
</source>
To samo inny sposób:
<source lang=php>
$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'; ?>
</source>

''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.

=== Essential Interaction Parameters ===
Wszystko jest na miejscu:
* Main i dedykowane kontrolery;
* Main i dedykowane modele;
* różne widoki i ich formy.

Pozostaje jedeno wielkie pytanie: '''Jak z nich korzystać'''!

Trzy parametry są obowiązkowe do wykonania zadania w Joomla!:
* option
* controller
* task

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.

==== How it all works together ====
Patrząc na uproszczony obraz MVC Joomla! logiczny strumień interakcji wygląda w następujący sposób:
# Jaki jest mój punkt wejścia? 
#*silnik Joomla! wykrywa zalogowany administrator i ustawia punkt wejścia <root>/administrator/index.php jesli nie <root>/index.php. 
# O którą opcję prosisz? 
#*Silnik Joomla! czyta zmienną option i odkrywa, że komponent nazwa się <componentname> jest poproszony o. Punkt wejścia dostaje: <root>/administrator/components/com_<componentname>/<componentname>.php
# Czy potrzebujesz innego kontrolera?
#*Silnik Joomla! czyta zmienną controller i odkrywa, że inny kontroler jest wymagany: <root>/administrator/components/com_<componentname>/controllers/<dedicatedcontroller>.php 
# Czy jest task, który musi zostać wykonany?
#*Zidentyfikowany kontroler dostaje wartość zadania jako parametr. 
# Model wywodzi się z kontrolera i instancji.
# Widok i forma są w kontrolerze i zainicjowane by stać się aktywnymi.

=== How to add interaction ===
W HTML, są dwa sposoby komunikowania się z Joomla!:
# Poprzez link
# Przesyłanie przez form post / get

==== Link reference for the Joomla! engine ====
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:
<source lang=php>
$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>";
</source>

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]

==== Posting Form Data to the Joomla! Engine ====
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).

<source lang="php">
<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>
</source>

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 <code>method="post"</code> tymczasowo na <code>method="get"</code>. 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''.

== Conclusion ==

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.

== Artykuły z tej serii ==
* [[Projektowanie komponentu według wzorca Model-Widok-Kontroler - Część 1]]
* [[Projektowanie komponentu według wzorca Model-Widok-Kontroler - Część 2 - Dodanie_modelu]]
* [[Projektowanie komponentu według wzorca Model-Widok-Kontroler - Część 3 - Korzystanie z bazy danych]]
* [[Projektowanie komponentu według wzorca Model-Widok-Kontroler - Część 4 - Tworzenie interfejsu administracyjnego]]
* [[Projektowanie komponentu według wzorca Model-Widok-Kontroler - Część 5 - Podstawowy framework zaplecza]]
* [[Projektowanie komponentu według wzorca Model-Widok-Kontroler - Część 6 - Dodanie akcji zaplecza]]

== Contributors ==
* staalanden
* jamesconroyuk
{{Jdocs|http://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_4_-_Creating_an_Administrator_Interface}}
<noinclude>
[[Kategoria:Poradniki]]
[[Kategoria:Programowanie komponentów]]
[[Kategoria:Programowanie]]
</noinclude>