[php]programowanie obiektowe (czy jest dobrze), na początek system formularzy Opcje

[Lejto]

Postanowiłem się w końcu zacząć uczyć programowania obiektowego. Na początek napisałem skrypt który graweruje formularze. Czy kod jest optymalny? Co w nim jest niepotrzebne a co zmienić?

[PHP] pobierz, plaintext 
<?
class mech_form
{
 
	function utworz($action, $nazwa, $metoda)
	{
		echo '<form action="'.$action.'" name="'.$nazwa.'" method="'.$metoda.'">';
	}
 
	function utworzPoleInput($type, $size, $value)
	{
		$a = new tworzHTML();
		$a->PoleInput($type, $size, $value);		
	 }	  
 
}
 
class tworzHTML extends mech_form 
{
 
	function PoleInput($type, $size, $value)
	{
		echo $nazwa.'<input type="'.$type.'" size="'.$size.'" value="'.$value.'">'; 
	}
 
}
 
$mech_form = new mech_form();
   
 
?><br />
<?
	$formularz = $mech_form->utworz('formularz', 'Nazwa', 'post');
	?>
	<table>
		<tr>
			<td>Nick: </td>
			<td><? $mech_form->utworzPoleInput('text', '3', 'ELO'); ?>
			</td>
		</tr>
	</table>
	</form>
[PHP] pobierz, plaintext 

[dr_bonzo]

W jakim celu
1. klasa tworzHTML rozszerza mech_form
2. istnieje klasa tworzHTML

pozatym: dla tak prostej funkcjonalnosci wystarcza funkcje, krocej sie pisze.

Ten post edytował dr_bonzo 27.04.2008, 16:57:51

[marcio]

Kiedys jak tez sie chcialem uczyc OOP to tez napisalem cos takiego

[PHP] pobierz, plaintext 
<?php
class Html_code {
 
protected $action, $method, $name, $type, $value, $rows, $cols, $style, $html;
 
public function new_form($action, $method) {
 
  return '<form method="'.$method.'" action="'.$action.'">';
  }
 
public function text_input($name, $type, $value = '', $style) {
 
  return '<input type="'.$type.'" name="'.$name.'" value="'.$value.'" style="'.$style.'">';
  }
 
public function textarea($name, $value, $rows, $cols, $style) {
 
  return '<textarea name="'.$name.'" cols="'.$cols.'" rows="'.$rows.'" style="'.$style.'">'.$value.'</textarea>';
  }
 
public function button($name, $type, $value, $style) {
 
  return '<input type="'.$type.'" name="'.$name.'" value="'.$value.'" style="'.$style.'">';
  }
 
public function html($html) {
 
  return $html;
  }
};
?>
[PHP] pobierz, plaintext 

Moze ci sie przyda

[phpion]

Moim zdaniem tego typu metody lepiej deklarować jako statyczne. Jeśli chciałbyś sobie podejrzeć inne rozwiązania to możesz zobaczyć te, które są wbudowane we framework Kohana:
HTML
Form
Proste, a przy tym cholernie użyteczne i przydatne

[marcio]

HEh @phpion te klasy sa o duzo wiecej rozbudowane i bardziej skomplikowane jak dla mnie ja wole cos mojego i latwego za pomoca tamtej klasy napisalem nawet ksiege gosci i dziala ogolnie OOP sie nie zajmuje ale dobrze wiedziec ze takie cos instnieje

[Sedziwoj]

Moim zdaniem tego typu metody lepiej deklarować jako statyczne. Jeśli chciałbyś sobie podejrzeć inne rozwiązania to możesz zobaczyć te, które są wbudowane we framework Kohana:
HTML
Form
Proste, a przy tym cholernie użyteczne i przydatne

Może i proste, ale nie przydatne, nawet warstwa widoku nie jest wydzielona. Do tego to kod proceduralny zamknięty w obiekcie.
Tak aby nie być gołosłownym, to mamy obiekt formularza, który ma pola, każde pole ma swój typ, nazwę, walidację...
To było by obiektowe, a nie takie coś.

EDIT literówka

Ten post edytował Sedziwoj 27.04.2008, 22:47:40

[Cysiaczek]

Obiektowo chcecie? Proszę: http://www.plentyofcode.com/2008/04/7-days...symfony-11.html

Pozdrawiam

[phpion]

@Sedziwoj masz rację ale:
- kolega zaczyna zgłębiać OOP,
- średnio wyobrażam sobie wydzielenie warstwy widoku dla jednego inpucika moim zdaniem przerost formy nad treścią.

[Sedziwoj]

Obiektowo chcecie? Proszę: http://www.plentyofcode.com/2008/04/7-days...symfony-11.html

Na pewno przeczytam, ale nie teraz...

@Sedziwoj masz rację ale:
- kolega zaczyna zgłębiać OOP,

Powiedz szczerze, czy brałeś to w ogóle pod uwagę, bo mi się wydaje że nie, więc nie pisz o tym innym, do tego to nie jest meritum sprawy.
Do tego piszesz o OOP, a nie o klasach, więc OOP to nie jedna klasa, ale to chyba wiesz.

- średnio wyobrażam sobie wydzielenie warstwy widoku dla jednego inpucika moim zdaniem przerost formy nad treścią.

Ech, no i właśnie tak powstaje syf w aplikacjach, "po co widok, przecież to tylko jedno echo". Nie chce mi się tłumaczyć dlaczego to jest dobre rozwiązanie, bo to jakby tłumaczyć dlaczego używać wzorca MVC (tudzież MVP).

[Lejto]

napisałem takie coś:

[PHP] pobierz, plaintext 
<?php
class mech_tabele
{
 
	function utworz_tabele($class, $align, $bordercolor, $border, $cellpadding, $cellspacing, $id)
	{
		echo '<table class="'.$class.'" align="'.$align.'" bordercolor="'.$bordercolor.'" border="'.$border.'"
		 cellpadding="'.$cellpadding.'" cellspacing="'.$cellspacing.'" id="'.$id.'">';
	}
	function utworz_wierssz()
	{
		echo '<tr>';
	}
	function utworz_kolumne($bgcolor,$tekst)
	{
		echo '<td bgcolor="'.$bgcolor.'"><b>'.$tekst.'</b>';
	}	
	function zamknij_wiersz()
	{
		echo '</tr>';
	}
	function zamknij_kolumne()
	{
		echo '</td>';
	}		
	function zamknij_wszytko()
	{
		echo '</td></tr></table>';
	}	
}
 
 
 
 
$mech_tabele = new mech_tabele();
		 
				$mech_tabele->utworz_tabele('ucz', 'center', '#000000', '1', '1', '0', 'problem');
				 $mech_tabele->utworz_wierssz();
				$mech_tabele->utworz_kolumne('#FF3030', 'Problem:');
				$mech_tabele->zamknij_kolumne();
				$mech_tabele->zamknij_wiersz();
				$mech_tabele->utworz_wierssz();
				$mech_tabele->utworz_kolumne('#FF3030', '');
				 throw new Exception('Formularz wypełniony nieprawidłowo<br><br>');
				$mech_tabele->zamknij_wszytko();
?>
[PHP] pobierz, plaintext 

opłacalne? czy oprzeć na tablicy czy może jakoś inaczej?

[bim2]

Ja tu z obiektowości nie widze nic poza słowem class

Klasa ma ułatwić programowanie, przyszybszyć je, a w twoim wypadku tylko spowalnia. Licz ile literek to zamknij_kolumne() a ile to </td> ?

Wywal wszystko co masz, co wiesz. Poczytaj jeszcze raz, pooglądaj przykłady w "Algorytmy, klasy funkcję" i napisz coś co się przyda, nic na siłę.

[Crozin]

Kod HTML generowany przez to nadaje się tylko do kosza - od formatowania jest CSS
W dodatku trzeba wywoływać masę niepotrzebnych metod - wcale nie jest to wygodniejsze od ręcznego wklepania.

Generalnie nie ma chyba jakiegoś sztywnego wzorca - wszystko powinno być stworzone tak, aby działało jak najlepiej pod konkretny projekt.

Może to być coś takiego:

[PHP] pobierz, plaintext 
<?php
$table = new table(4); //ilość kolumn
$table->addCell('trescKolumny1')->addCell('kolumny2');
//....
$table->addCell('kolumny3')->addCell('czwartej');
//...
$table->addCell('kolumny1 - wiersza 2 (samo przerzuci)');
?>
[PHP] pobierz, plaintext 

Ale jak napisałem - powinno to być zrobione pod konkretne zadanie.

[Strzałek]

Przede wszystkim - generowanie HTML za pomocą różnorodnych klas to jakaś pomyłka jest (przynajmniej dla mnie). Html się klepie ręcznie i tyle. Dla mnie to przerost formy nad treścią.

A kolega chce się nauczyć programowania obiektowego? Najlepiej uczyć się na jakiś przykładach. Poczytaj sobie kod frameworków - Symfony, Agavi, czy nawet ZF to powinno w pewnym momencie zaskoczyć własciwe rozumowanie

[Sedziwoj]

Przede wszystkim - generowanie HTML za pomocą różnorodnych klas to jakaś pomyłka jest (przynajmniej dla mnie). Html się klepie ręcznie i tyle. Dla mnie to przerost formy nad treścią.

W tych rzeczach co właściwie wyłącznie pojawiają się na forum, to tak, takie html w php...
Ale jak zamyka się większe logiczne komponenty i mają one swój sposób wyświetlania to inna sprawa.
Chociażby stronicowania, coś co generuje odpowiednie rzeczy, ładny obiektów kod, tylko co ma zrobić, nie jak, a potem jest szablon to prezentujący, wtedy grafik ma dostęp do niego może zmieniać, a obiektowość (czy w tym przypadku może jedna klasa) jest niewidzialna dla niego, a dla programisty nie ma html.
Może to proste napisanie tego, ale po co się bawić w stronicowanie za każdym razem, gdy parametrów jest niewiele ile stron, która obecnie, ile ma wyświetlić numerków w przód i tył itp., najczęściej będą tylko dwa używane, więc mając taki komponent to chwila i ma się stronicowanie.

To samo można osiągnąć w formularzach, ale to większa zabawa...
(hm, jeszcze nie miałem czasu przeczytać tego co Cysiaczek dał linka :| )

[bziur]

Powiem tak - dla mnie programowanie obiektowe przejawia sie nie tylko w kawalku kodu, ktory nazywa się klasa - jest to makro na makro, a wiec jedna wielka klasa generuje jeden wielki obiekt, a w kodzie nam to zajmuje kilka linijek. Uzywanie klas do generowania pojedynczych znacznikow HTML jest przelozeniem macro na micro, czyli wielka klasa generuje maly kod, a to juz niedobrze, bo marnuja sie bajciki 

Bardzo dobrym przykladem dobrze napisanego obiektu-klasy jest klasa FCKeditora, ktorego kod tego typu:

[PHP] pobierz, plaintext 
<?php
$FCKeditor['articleText'] = new FCKeditor('text') ;
$FCKeditor['articleText']->BasePath		= 'FCKeditor/';
$FCKeditor['articleText']->ToolbarSet	= 'Default';
$FCKeditor['articleText']->Value		= 'testowy text';
$FCKeditor['articleText']->Height		= 400;
$FCKeditor['articleText']->Width		= '100%';
?>
[PHP] pobierz, plaintext 

generuje nam taki ladny edytor jak przedstawiony w odsylaczu: http://www.fckeditor.net/demo/language

[Athlan]

Po 1.
http://forum.php.pl/index.php?s=&showt...st&p=466253
Kolejne nie-OOP, kopiujesz metody jak popadnie. Nie lepiej miec metody, które wyzwalają inną metodę (wpisują typ i zakres danych) np protected $this->_pole_input( paramy ) i zastępują tylko type.

Po 2. Po grzyb pisać generator formularzy ? zawsze znajdzie się jakiś parametr, który odrzuci klasę, np dodatkowe atrybuty. Warto o tym pomyśleć i oprócz name itd dorobić metody addAttribute($sName, $sValue).

Po 3. Fajnie by było rozszerzyć takie klasę o validację, pobieranie wartości z POST'u jeżeli są przesłane, a jeżeli nie to z bazy danych (jeżeli to edycja czegoś, po postowaniu dane z bazy zamieniają się na dane z POST'u chwilowo w wyświetleniu formularza).

Ogólnie to nie OOP