Próbuję utworzyć obiektowy generator formularzy. Pamiętaj, że będzie on używany tylko przez garstkę ludzi w naszej firmie, aby rozwiązać konkretny problem.Generator obiektowy PHP zorientowany obiektowo
Mam obecnie dwa małe zastrzeżenia.
Składnia tworzenia elementów
Istnieje kilka podejść mogę wziąć.
Ustawianie wszystkiego w konstruktorze. Jako wadę, może to spowodować inconsitent użycia konstruktora konstruktor
Input::create('text', 'name', array('maxlength' => 10));
graniczna rodzaju i widoczne tylko najczęściej stosowane cechy jak metodami (zawsze o jeden metody określania atrybutów masy)
Input::create('text')->name('name')->value('value')->attribute('max_length', 10);
wystawienia każdej atrybut jako metoda z utworzeniem metody dla każdego atrybutu lub metodą magiczną __call
, która spowoduje brak obsługi autouzupełniania w IDE. I nawet teraz mogę zachować metodę attribute
.
Input::create()->type('text')->name('name')->value('value')->max_length(10)->id('id'); //etc.
Obecnie uważam drugie podejście za najlepsze, ponieważ zachowuje "dobre" rzeczy z obu światów. Nadal stanowi sposób na streszczenie niektórych prac, ponieważ np. Metoda required
nie tylko ustawi wymagany atrybut, ale również oznaczy to pole dla obiektu sprawdzania poprawności zgodnie z wymaganiami.
Kod powielania Sposób 2 i 3
Ponieważ są cechy, które mogą być używane przez każdego elementu, a także atrybuty, które są użyteczne jedynie o 3 lub 4 elementy, np Atrybut HTML5 form
.
Każdy element może dziedziczyć z elementu podstawowego, który ma metody dla atrybutów uniwersalnych dla każdego elementu (np. name
). Częściowo użyteczne atrybuty można rozwiązać za pomocą interfejsów, ale prowadzi to do powielania kodu, ponieważ nie mogą zawierać treści metod.
Cechy będą rozwiązaniem, ale niestety, utknąłem w PHP 5.3 bez możliwości uaktualnienia. Pozostaje mi to albo zaimplementować wzorzec Mixin albo Composition, co może ponownie doprowadzić do braku obsługi autouzupełniania. Zostałoby to częściowo złagodzone przy stosowaniu drugiego podejścia.
więc do mojego aktualnego pytanie:
Które podejście może skończyć jako najbardziej odpowiedni? (odpowiednie jak w przypadku minimalnego powielania kodu, wielokrotnego ponownego użycia kodu i łatwości implementacji)
Zdaję sobie sprawę, że może to bardzo dobrze odrodzić odpowiedzi oparte na opiniach, więc z góry przepraszam, jeśli tak.
jest 'Wejście :: create()' tylko metody fabryki do tworzenia prawdziwych „obiektach wejściowych”? Byłem zdezorientowany, odkąd kilka razy wspomniałeś o konstruktorze, ale nigdy nie pokazałeś swojego konstruktora. Również dla twojego problemu z dziedziczeniem są klasy abstrakcyjne. Mogą mieć treść metody i mogą przekazywać szczegóły implementacji swoim dzieciom, definiując abstrakcyjne metody bez ciała. – thpl
Input :: create() tworzy autonomiczny obiekt wejściowy, ale wiele elementów, np. Textarea, Button będzie miał różne parametry konstruktora. Jak już powiedziałem, każdy element może dziedziczyć z elementu podstawowego (klasa abstrakcyjna), ale mówimy o dziedziczeniu pojedynczym, a więc duplikacji kodu przy użyciu wielu elementów bazowych (ponieważ nie chcę atrybutów, które można ustawić tylko dla danych wejściowych w obszarze textarea). Używanie wielu elementów bazowych z interfejsami również powodowałoby powielanie. – realshadow
Czy kiedykolwiek zastanawiałeś się, co się teraz dzieje, np. Https://github.com/naomik/htmlgen? – Tschallacka