2010-03-05 9 views
6

Tworzę bibliotekę obiektów wyświetlanych dla naszej aplikacji. Reprezentują one html wielu popularnych obiektów (użytkowników, rozmów, wiadomości itp.) W różnych widokach. Według poglądów mam na myśli, że obiekt może pluć z powrotem różne "poziomy powiększenia" z różnymi znacznikami.Zend Framework - Kiedy używać viewscripts/partials a view helpers

Niektóre obiekty wyświetlane zawierają inne obiekty wyświetlania do renderowania, np. obiekt listy użytkowników renderuje obiekty użytkownika w określonym widoku (ten konkretny widok przesuwa je z powrotem na pozycje listy, aby zmieściły się na liście)

Próbuję przenieść je we właściwy sposób robienia rzeczy w ZF, ale Nie mogę zdecydować, czy wszystkie powinny być widokami pomocników, czy też wszystkie są widokami skryptów/części.

Samo wyświetlanie skryptów i renderowanie ich za pomocą -> render() wydaje się być trochę brudne, ponieważ wszelkie informacje lub parametry, które chcę do nich przekazać, muszą zostać przypisane do obiektu widoku.

Częściowe wydają się trochę bardziej poprawne, z wyjątkiem nie pewności, czy właściwe jest wykonywanie logiki wyświetlania w tych (jeśli parametr "showNotificationStatus" jest przekazywany jako parametr, renderuj ten zakres). Lub jeśli jest to koszerne dla częściowych renderowania innych części (lista użytkowników renderująca obiekt użytkownika).

Zobacz, jak pomocnicy wydają się być właściwym sposobem na zrobienie tego, ale nie wiem, czy to nadużywa pomocników widoku. Każdy obiekt może być pomocnikiem widoku i zaakceptować parametr podglądu obiektu, dzięki czemu wiedział, jaki poziom powiększenia/kontener ma się wyświetlać, lub każdy widok obiektu mógłby być nawet jego własnym pomocnikiem (więc nie ma dużej instrukcji przełączania wewnątrz obiektu). Jedną dobrą rzeczą w widokach jest to, że możesz przekazywać parametry i nadal ma dostęp do kontekstu widoku, jeśli potrzebujesz czegoś z tego poziomu.

Większość z nich będzie akceptować modele, z których kilka wymaga dodatkowych parametrów, aby wiedzieć, co robić (np. ShowNotificationStatus z góry). Jakie jest odpowiednie narzędzie do tego?

Odpowiedz

15

Jedną z podstawowych idei częściowych jest to, że mają być one jak najbardziej możliwe do ponownego użycia - stąd ich własny zakres zmiennych. Lubię używać partials jako dość niemy pojemników na małe kawałki HTML. Nie ma większej logiki niż kilka instrukcji if() lub .

Jeśli potrzebuję poważnej logiki - używam pomocnika. Pomocnicy powinni być odpowiedzialni za obsługę logiki i wywoływanie metod renderowania. Wiem, że w świecie Railsów pomocnicy mają tendencję do zamykania małych elementów logiki, takich jak obsługa linków lub tagów graficznych. To jest świetne, ale nie sądzę, że istnieje jakakolwiek szkoda, czyniąc je bardziej złożonymi w ZF. Zasadniczo używam ich do tłumaczenia moich obiektów biznesowych na widoki.

Myślę, że najlepszym sposobem wykorzystania zarówno częściowych, jak i pomocniczych, jest pomocników, którzy ustawiają dane, a następnie przekazują je do częściowych. W ten sposób twój kod HTML pozostaje bardzo łatwy w utrzymaniu (i podejrzewam, że za każdym razem, gdy ktoś wpisuje echo "<a href='". $my_link . '"/>", gdzieś umiera kotek).

EDIT (opracowanie):

, aby pamiętać o pomocników jest to, że mogą być one traktowane jak normalne zajęcia, należy użyć konstruktora z argumentami i mają członków prywatnych.Więc kiedy tworzysz helpera, możesz obiekt biznesowy, a następnie masz wiele metod renderujących HTML (przez częściowe).

Więc moim zdaniem:

<?php $helper = $this->_helper->MyUserHelper($users); ?> 
<ul> 
    <?php $helper->user_list(); ?> 
</ul> 

Tutaj metoda user_list() zwraca kolekcję <li> elementów z wszystkich odpowiednich danych w nich.

Mój pomocnik potęga wygląda następująco:

class MyWidgetHelper 
{ 
    private $_widget; 

    public function __construct($users) 
    { 
    $this->_users = $users; 
    } 

    public function user_list() 
    { 
    // do any necessary logic here 
    // then return the html that gets rendered. 
    // you can call a partial from here, and it just returns an HTML string. 
    return $this->_view->partial('partials/_user_item.phtml', array('users' => $users) 
    } 
} 
+0

Bryan Myślę, że to naprawdę dobra informacja. Czy masz szansę trochę rozwinąć? Załóżmy, że masz obiekt biznesowy, który można przedstawić na różnych poziomach powiększenia (szczegółów). Czy masz jednego pomocnika, który renderuje różne cząstki na podstawie przekazanego parametru? Wielu pomocników z odpowiednimi częściami? Zasadniczo patrzysz na ogólnie związek 1 do 1? I czy to jest świetne, aby stronniczość mogła wykorzystać innych pomocników widoku? (Wyobraźmy sobie rozmowę, w której znajduje się lista użytkowników w środku.). Musisz renderować użytkowników w części rozmowy.) –

+0

Dodałem do mojej odpowiedzi a powyżej przykład. W moim przykładzie używam helperów do kontrolowania częściowych, ale nie rozumiem, dlaczego nie można tego zrobić na odwrót. Po prostu wolę zachować mój HTML wolny od logiki php, jak tylko mogę. –

+0

Znakomity. Dzięki, bryan! –

0

Pomocnicy są dla logiki (np. Konwertuj obiekt do tablicy), części są przeznaczone do dekorowania logicznego (wyświetlaj tablicę rekurencyjną jako drzewo <ul>). Można również użyć $this->render('anyfile.ext') lub include().

+0

Jedną rzeczą, która zaciera tę linię dla mnie, to są pomocnicy, że statek z ZF, które są właśnie dla tworzenia elementów HTML z dostarczonych danych. Zobacz wszystkie pomocników formularzy na http://zendframework.com/manual/1.10/en/zend.view.helpers.html np. formCheckbox tworzy pole wyboru z danymi, które mu przekazujesz. –

+1

Pomagające, które mogą mieć inne wyjście HTML, użyj 'setPartial()'. Gdy częściowe wykonanie jest zbyt kosztowne (lub masz pewność, że wynik będzie za każdym razem taki sam), łatwiej będzie po prostu zakodować kod HTML w helperie. Wystarczy zaimplementować 'setPartial()' z powrotem do domyślnego znacznika, jeśli częściowa nie jest ustawiona. – takeshin