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ć?

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

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

~ 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

~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.

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ę.

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.

Pisząc to


Właśnie mieszasz poszczególne elementy.

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

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)

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.

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

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

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.