[HTML][PHP]Programowanie obiektowe, jak nie mieszać logiki z HTMLem Opcje

[gargamel]

Przyszedł czas przestawić się na programowanie obiektowe, ale żeby od razu źle nie zacząć, mam pytanko.

Napisałem prostą klasę (do generowania formularzy), aby od czegoś zacząć:

[PHP] pobierz, plaintext 
class formClass
{
public $output;
public $startedGroup;  
 
  public function formGroup(){
    if($startedGroup){
    $this -> output .= "</div>\n";
    }
  $this -> output .= "<div>\n";
  $this -> startedGroup = true;
  }
 
  public function formElement($name){
  $this -> output .= "<div>".$name.": <input type='text' name='".$name."' /></div>\n";
  }
 
  public function printForm(){
  $this -> output .= "</div>\n";
  echo $this -> output;
  }
}
 
$form = new formClass;
 
$form -> formGroup();
$form -> formElement('imie');
$form -> formElement('nazwisko');
$form -> formElement('wiek');
 
$form -> formGroup();
$form -> formElement('adres_email');
$form -> formElement('telefon');
 
$form -> printForm();
[PHP] pobierz, plaintext 

I teraz problem... wszędzie pisze się aby nie mieszać logiki z HTMLem, a ja tu nie widzę żadnej możliwości, aby wywoływane metody nie zwracały HTMLa...
W jaki sposób powinno się prawidłowo coś takiego robić?

[smietek]

Użyj jakiegoś systemu szablonów (np. Smarty) lub napisz jakiś prosty, własny.

[lobopol]

Raczej w mieszaniu html z php chodzi oto aby nie robić czegoś takiego:

[PHP] pobierz, plaintext 
<div>aaa</div>
 
<?php 
function a(){
return 'a';
}
$a = 'b';
echo $a;
?>
 
<div>bb</div>
<?php $a=a();?>
[PHP] pobierz, plaintext 

.itd

Powinieneś oddzielić od siebie warstwę która ustawia wartości zmiennych, przyjmuje dane i je obrabia o warstwy która ją wyświetla. Idealnym przykładem jest mvc
Masz tam podział na
modele->tu masz metody i funkcje pobierające np. dane z bazy, zapisujące je itd. Po prostu zbiór funkcji i metod
kontrolery->odbiera wszystkie akcje użytkownika i uruchamia metody z modelu i odpala widok
widoki tu po prostu masz to co chcesz wyświetlić użytkownikom ( tu dajesz echa )

I taka rada ode mnie nie dawaj w metodach echo. Daj return i po w widoku to co zwróci wyswietl

[darko]

~ gargamel: przeczytaj chociaż przypięty wątek o MVC; w printForm powinieneś zrobić return $this->output i to, co zwróci ta metoda przekazać do widoku. A tak na dobrą sprawę - podpatrz sobie rozwiązania frameworkowe i jak to tam zostało rozwiązane, np. Zend_Form albo sfForm
~ lobopol: a jak wyobrażasz sobie szablony phtml, bo właśnie analogicznie się z nich korzysta
~ smietek: Smarty to przeżytek, już lepiej pisać natywne .phtmlki mieszając kod php z htmlem

[naunus]

~darko: Nie zgodzę się z Tobą, że Smarty to przeżytek. Może i mieszanie na chama html'a z phpem jest łatwiejsze, ale Smarty sprawiają że strona jest bardziej "elegancka" i przejrzysta od strony źródła oraz umożliwia łatwe korekty.

[darko]

Smarty jest strasznie niewydajne i ociężałe. W większych projektach jest elementem, jednym z wielu, które należy "uszczuplić" w pierwszej kolejności. Nie przekonasz mnie, że coś jest lepsze od najprostszego i najwydajniejszego sposobu czyli wyskoczenia z sekcji, którą przetwarza interpreter php i wskoczenia z powrotem do html. To, jak Ty zorganizujesz, będzie miało też wpływ na ogólną wydajność aplikacji. Pozwolę sobie zalinkować temat z 2009 r.:
http://forum.php.pl/index.php?showtopic=111418
http://www.forum.optymalizacja.com/index.php?showtopic=26150
http://forum.php.pl/index.php?showtopic=5562&mode=linear
http://forum.php.pl/index.php?showtopic=58...=0&p=318072
jak widać zdania są podzielone, ale z przewagą głosów "za" niż "przeciw". Każdy ma swoją filozofię, którą widać w kodzie. Jeden lubi Smarty, drugi woli zrobić to samo inaczej. Ja osobiście wolę nie obciążać aplikacji dodając kolejną warstwę prezentacji. Ma to swoje zalety i wady, których jestem świadomy. Wiem co tracę i co zyskuję.

[gargamel]

Znaczy tak: Smarty takie czy inne i tak będę musiał wykorzystać. Chcę dać użytkownikom możliwość edycji ich szablonu strony w całości, oraz udostępnić elementy dynamiczne takie jak np. imię czy nazwisko zalogowanego...
Problem jest takiej kategorii, że jak zaczynałem pisać system, to w założeniu miał on być mały, ale po roku rozrósł się strasznie i teraz przy zmianie czegokolwiek można się zarobić. Przepisuję go na nowo i chcę oprzeć na modelu MVC właśnie... Wiem jak go zastosować w przypadku zarządzania nie wiem, danymi tabelarycznymi, ale nie do końca wiem jak mam taki model (i czy w ogóle jest sens) zastosować w przytoczonym przykładzie tworzenia formularza.

[konole]

Pisząc to

Kod

public function formElement($name){
  $this -> output .= "<div>".$name.": <input type='text' name='".$name."' /></div>\n";
}

Właśnie mieszasz poszczególne elementy.

[gargamel]

hmm, co racja to racja.. ale zaraz, ja chyba dlatego właśnie założyłam ten temat ?!

[Crozin]

Zacznij może od tego, że ten kod to do kosza się jedynie nadaje.

1. Można dodawać jedynie elementy INPUT z typem TEXT? A co z ~20 pozostałymi standardowymi kontrolkami udostępnianymi przez HTML?
2. Nie ma możliwość żadnej ingerencji w "szablony". Myślisz, że zawsze konstrukcja <div>{{ LABEL }} {{ INPUT }}</div> się sprawdzi? Każdy szablon (formularza, grupy elementów, samego elementu, etykiety i w końcu kontrolki HTML) powinien być modyfikowalny.

No i jeszcze kilka rzeczy co do podstaw OOP i dobrych praktyk:
1. Nazwy klas powinny być rzeczownikami i rozpoczynamy je wielką literą, np.: FormDecorator.
2. Nazwy metod to czasowniki określające co ma zrobić obiekt, np.: addElement (Dekoratorze formularza dodaj element).
3. Z punktu #2 można łatwo wywnioskować, że metoda [i]formGroup jest kompletnie bezsensu. Powinno być addGroup gdzie jako pierwszy argument przekazuje się grupę (obiekt, który zawiera elementy)

I teraz problem... wszędzie pisze się aby nie mieszać logiki z HTMLem, a ja tu nie widzę żadnej możliwości, aby wywoływane metody nie zwracały HTMLa...
W jaki sposób powinno się prawidłowo coś takiego robić?

Skoro zadaniem tej "logiki" jest generowanie HTML-a to chyba oczywiste jest, że musi ona zwrócić ten HTML, co nie?

Swoją drogą, takie coś powinno być bezpośrednio powiązane z frameworkiem obsługi formularzy inaczej naprawdę niewiele zyskujesz tworząc coś takiego.

Ten post edytował Crozin 18.03.2011, 19:26:28

[gargamel]

Zacznij może od tego, że ten kod to do kosza się jedynie nadaje.

1. Można dodawać jedynie elementy INPUT z typem TEXT? A co z ~20 pozostałymi standardowymi kontrolkami udostępnianymi przez HTML?

To napisane tylko do tego aby był punkt wyjścia do rozmowy

2. Nie ma możliwość żadnej ingerencji w "szablony". Myślisz, że zawsze konstrukcja <div>{{ LABEL }} {{ INPUT }}</div> się sprawdzi? Każdy szablon (formularza, grupy elementów, samego elementu, etykiety i w końcu kontrolki HTML) powinien być modyfikowalny.

O to głównie mi chodziło, jak ten przykład przekształcić "aby było prawidłowo".

No i jeszcze kilka rzeczy co do podstaw OOP i dobrych praktyk:.......

Dziękować za rady

[Crozin]

Podejrzyj sobie Zend_Form z ZF czy komponent Form z Symfony2 (albo ze Springa bo Sf2 w dużej mierze właśnie na nim bazuje). Jest to temat tak rozległy, że w jednym wątku się z nim nie zmieścimy.