Poprzedni post demonstruje dużo pracy przy przejmowaniu czegoś, co kiedyś było szybkim prototypem, i przejmowaniu tego prototypu do kodu. Jeśli nie śledziłeś dalej, zrobiliśmy następujące rzeczy:
- omówiłem i zbudowałem prototyp wtyczki,
- schematycznie jedno podejście obiektowe może działać,
- i refaktoryzacji naszego prototypu do rzeczywistego kodu.
W tym momencie jest jeszcze kilka rzeczy, które możemy zrobić, aby ulepszyć nasz kod. Mianowicie możemy wprowadzić pojęcie przestrzeni nazw. To przenosi organizację o krok dalej i może wypłacać dywidendy za większe projekty.
Oto więc, jak to wygląda w naszym obecnym projekcie.
Prototyp do kodu: przestrzenie nazw
W poprzednich postach szczegółowo omówiłem przestrzenie nazw. Jeśli nie czytałeś, polecam. Następnie wróć i sprawdź resztę postu.
Jeśli zdecydujesz się pominąć ten artykuł, oto krótka definicja przestrzeni nazw :
Przestrzenie nazw mają na celu rozwiązanie dwóch problemów, które napotykają autorzy bibliotek i aplikacji podczas tworzenia elementów kodu wielokrotnego użytku, takich jak klasy lub funkcje…
Ogólną ideą jest to, że organizujemy nasze zajęcia w oparciu o logiczną relację, jaką mają ze sobą.
Ponadto organizujemy również pliki w katalogach, które pasują do przestrzeni nazw. Nie jest to coś, co trzeba zrobić, ale uważam, że pomocne jest logiczne uporządkowanie klas na dysku w taki sposób, w jaki są wirtualnie zorganizowane w przestrzeni nazw.
Powiedziawszy to, uporządkujmy pliki.
Organizowanie plików
Zamiast zaczynać od głównego pliku wtyczki, zacznijmy od uporządkowania naszych plików.
- Pliki Meta Box i Meta Box Display będą znajdować się w katalogu o nazwie Display. Jest to całkowicie arbitralne, ale ponieważ tak robią te pliki, wydaje się sensowne, że właśnie tam się znajdują.
- Możemy również umieścić w tym katalogu pliki message-description.php i no-post-list.php, ale umieśćmy je w podkatalogu o nazwie Views. Możesz nazwać to Szablony lub Częściowe lub w podobny sposób.
- Następnie mamy klasy odpowiedzialne za odpytywanie bazy danych oraz klasę odpowiedzialną za koordynację przesyłania komunikatów. Umieśćmy każdy z nich w Utility. Oczywiście, są inne miejsca, do których mogą się udać, ale pamiętaj, że ich celem jest zademonstrowanie, jak używać przestrzeni nazw. Więc jeśli masz ochotę, możesz dostosować swoje pliki do własnych upodobań.
Jeśli śledziłeś to, co mamy powyżej, powinieneś mieć strukturę katalogów, która wygląda mniej więcej tak:
Jeden ze sposobów organizowania plików.
Teraz nadszedł czas na zdefiniowanie przestrzeni nazw dla każdej z klas. Ponieważ zorganizowaliśmy je wszystkie w ich katalogach, łatwo będzie określić przestrzeń nazw; jednak ważne jest, aby pamiętać, że będziemy musieli użyć słowa kluczowego use, gdy używamy klas znajdujących się w innych przestrzeniach nazw.
Przejrzyjmy każdy z naszych plików, zaczynając od plików w Utility. Najpierw zaczniemy od Post Messenger :
Zauważysz, że przestrzeń nazw pliku pojawia się w nagłówku wraz z deklaracją użycia utworzonej przez nas klasy Post Query . Dołączyłem nazwę klasy na końcu przestrzeni nazw, więc nie muszę jej używać w całym kodzie.
Zauważ, że konstruktor wygląda teraz tak :
Dodałem argument $plugin_dir, ponieważ musimy go użyć, aby poprawnie wyświetlić wyniki zapytania. A ponieważ znajdują się teraz w innym obszarze aplikacji, funkcje wyglądają tak :
Następnie spójrzmy na klasę Post Query . W tej klasie niewiele się zmieniło, z wyjątkiem tego, że nadaliśmy jej przestrzeń nazw, a także zaktualizowaliśmy zapytanie tylko po to, aby wycofać trzy posty (jak w tym komentarzu ).
Zauważ w kodzie, że dodałem również prefiks WP_Query z ukośnikiem, ponieważ jest to część globalnej przestrzeni nazw.
Przejdźmy do katalogu Display i przyjrzyjmy się klasie Meta Box. To również otrzymało przestrzeń nazw i używa w pełni kwalifikowanej nazwy klasy Meta Box Display, której przyjrzymy się za chwilę.
Zauważ, że ten konstruktor również akceptuje katalog wtyczek jako argument i przekazuje go również do klasy Meta Box Display. Dzięki temu funkcje odpowiedzialne za wyświetlanie komunikatów można poprawnie znaleźć w ich lokalizacji w katalogu Views.
Na koniec przyjrzyjmy się klasie Meta Box Display. Jest to prosta klasa, która zawiera przestrzeń nazw i odwołuje się do Post Messengera, który omówiliśmy powyżej.
W tym momencie zatoczyliśmy pełne koło przez wtyczkę. Z jednym wyjątkiem: plik ładujący. Dodaliśmy do niego przestrzeń nazw i musimy zaktualizować sposób jej tworzenia :
Mianowicie mamy:
- zdefiniował przestrzeń nazw,
- odwołać się do lokalizacji klasy Meta Box ,
- zaktualizowałem ścieżki, aby uwzględnić gdzie znaleźć pliki (co docelowo można zrobić za pomocą autoloadera),
- i zaktualizowałem wywołanie add_action .
Oto kwestia wywołania akcji add: Ponieważ WordPress musi zlokalizować tę funkcję, a funkcja znajduje się w przestrzeni nazw, w pełni kwalifikowana nazwa funkcji musi zostać zidentyfikowana, aby WordPress mógł ją wywołać. Stąd potrzeba NAMESPACE w nazwie funkcji.
Teraz jesteśmy zorganizowani (z jednym wyjątkiem)
Jak widać, pasujące do nich przestrzenie nazw i katalogi dodają dużo organizacji do projektu. Łatwiej jest śledzić, łatwiej zrozumieć, dokąd zmierzają rzeczy (zarówno w przypadku istniejących, jak i nowych plików). I daje mniej wrażenia, gdy gromadzi się wiele plików w jednym miejscu.
Nawet jeśli klasa jest trochę monolitem, nadal można ją zorganizować w taki sposób, aby ułatwić konserwację.
Mając to na uwadze, wciąż jest coś, co chciałbym zmienić w tej wtyczce: przekazywanie katalogu wtyczki w ten sposób nie jest czymś, co pomaga przy niskiej spójności i ściślej łączy klasy, ponieważ plik ładowania początkowego musi przekazać wartość do jedna klasa, która przekazuje go do innej klasy, która używa go do ładowania plików i tak dalej.
Czy są więc sposoby, aby to naprawić? Absolutnie. I być może przyjrzymy się temu w ostatnim poście.
Do tego czasu pamiętaj, że najnowsza wersja wtyczki jest dostępna w gałęzi master, oznaczona jako 0.3.0, na GitHub.
Posty z serii
- Szybkie prototypowanie z WordPress: od koncepcji do wtyczki
- Szybkie prototypowanie z WordPress: analiza koncepcji
- Szybkie prototypowanie: Prototypowanie do kodu, część 1
- Szybkie prototypowanie: Prototypowanie do kodu, część 2
- Szybkie prototypowanie: Przedstawiamy automatyczne ładowanie