2015-02-24 10 views
5

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.

+0

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

+0

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

+0

Czy kiedykolwiek zastanawiałeś się, co się teraz dzieje, np. Https://github.com/naomik/htmlgen? – Tschallacka

Odpowiedz

0

IMO wybrałbym drugą opcję. Prawdopodobnie dlatego, że przypomina mi jQuery.

Input::create('text')->name('name')->value('value')->attribute('max_length', 10); 

Zdefiniuj bardziej ogólnych dziedzinach, takich jak „nazwa”, „wartości”, „atrybut” w klasie interfejsu „FormElements” i wdrożenia/przedłużyć, że „wkład” klasach „Wybierz” etc.

Chociaż ja osobiście wolę tę drugą opcję .. w słowach Pawła obcego "Czasami trzeba rzucić kostką".

1

Zdaję sobie sprawę, że jest to stare pytanie, ale ktoś w komentarzach wspomina o projekcie, który utworzyłem pod nazwą naomik/htmlgen. Używam tutaj trochę wsparcia, ponieważ niedawno wydałem nową wersję 2.x, która sprawia, że ​​generowanie HTML jest całkiem przyjemne w PHP.

use function htmlgen\html as h; 
echo h('input', ['name'=>'catQty', 'value'=>500]) 

odda

<input name="catQty" value="500"> 

jednak, że przykład jest ledwie zarysowania powierzchni pod względem potencjalnego

h('#wrapper', 
    h('h1.title', 'Hello, World'), 
    h('p', 
    h('comment', 'link to project'), 
    h('a', ['href'=>'https://github.com/naomik/htmlgen'], 'See htmlgen on Github') 
) 
); 

Oto wyjście (rzeczywista moc nie ma spacji)

<div id="wrapper"> 
    <h1 class="title">Hello, World</h1> 
    <p> 
    <!-- link to project --> 
    <a href="https://github.com/naomik/htmlgen">See htmlgen on Github</a> 
    </p> 
</div> 

Jest również bardzo przydatny przy renderingu zbiory danych

use function htmlgen\html as h; 
use function htmlgen\map; 

$links = [ 
    'home' => '/', 
    'cats' => '/cats', 
    'milk' => '/milk', 
    'honey' => '/honey', 
    'donuts' => '/donuts', 
    'bees' => '/bees' 
]; 

echo h('nav', 
    h('ul', 
    map($links, function($href, $text) { return 
     h('li', 
     h('a', ['href'=>$href], $text) 
    ); 
    }) 
) 
); 

wynik byłby (ponownie, spacja jest tu tylko na wyświetlaczu)

<nav> 
    <ul> 
    <li><a href="/">home</a></li> 
    <li><a href="/cats">cats</a></li> 
    <li><a href="/milk">milk</a></li> 
    <li><a href="/honey">honey</a></li> 
    <li><a href="/donuts">donuts</a></li> 
    <li><a href="/bees">bees</a></li> 
    </ul> 
</nav> 

To wszystko jest 100% PHP i nie zwyczaj, opatentowane śmieszna sprawa. Jest bardzo ekspresyjny i nadaje się do świetnych kompozycji. Możesz podzielić swoje szablony na łatwe do ponownego użycia funkcje lub połączenia require.

Zapoznaj się z examples dłużej chłodne wskazówek