Jest to bardzo prosty i krótki wpis mówiący jak dodać biblioteki Zenda do projektu Symfony. Mimo, że to wymaga kilka linijek kodu, to często muszę tego używać i niestety ciągle zapominam :)

Na początku trzeba oczywiście skopiować folder Zend z bibliotekami. Należy go umieścić w folderze /lib/vendor.

Następnie jeszcze kilka linijek w głównym pliku konfiguracji ProjectConfiguration.php

require_once dirname(__FILE__).'/..\lib\vendor\symfony\lib/autoload/sfCoreAutoload.class.php';
sfCoreAutoload::register();

class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
  	set_include_path(sfConfig::get('sf_lib_dir').'/vendor'.PATH_SEPARATOR.get_include_path());
  	require_once sfConfig::get('sf_lib_dir').'/vendor/Zend/Loader/Autoloader.php';
  	Zend_Loader_Autoloader::getInstance();

  	$this->enablePlugins('sfDoctrinePlugin');
  }
}

I to by było na tyle :)

Symfony is very powerful PHP framework, one of the most popular in the PHP world. In big projects you should probably noticed, that there isn’t easy way to extend core classes, which aren’t returned by factories, for example actions classes. Every generated module has actions.class.php, which inherits from sfActions. What, if we want to have [...]

Few minutes ago Brent Shaffer asked on the Twitter Which is more standard, „public static function” or „static public function”? I was curious about it, so I’ve checked which convention is used in my favourite Symfony Project. Of course, I haven’t got enough time to check it manually, class by class, so I wrote simple [...]

Nie raz spotkałem się z problemem implementacji wielostronicowych formularzy w projektach w których uczestniczyłem, zazwyczaj były to formularze rejestracji, które składały się z 2-4 kroków. Podstawowe problemy które należy rozwiązać przy wykonywaniu formularza tego typu:

• możliwie jak najprostszy, spójny i elastyczny sposób przetwarzania formularza, aby ewentualne dodanie nowego pola lub całego formularza kosztowało jak najmniej nakładu pracy
• napisanie kodu, który będzie można również wykorzystać w przyszłości w innym projekcie

Istnieją dwa główne mechanizmy przechowywania danych z formularzy z poprzednich stron / kroków. Na pierwszy rzut oka zaprzęgnięcie sesji w tym celu wydaje się dobrym rozwiązaniem, jednakże czy tak w rzeczywistości jest? Sesja może wygasnąć podczas wypełniania długiego formularza lub też formularz może nie zostać w pełni wypełniony, co skutkuje przechowywaniem śmieci w sesji (rzutuje to również na wydajność). Oczywiście, można napisać coś w rodzaju garbage collection aby rozwiązać ten drugi problem, ale jest też inne rozwiązanie - przekazywanie danych z poprzednich kroków w ukrytych polach formularza. To również nie jest doskonałe, ale w mojej ocenie przysparza mniej problemów niż sesja.

Jeśli wiemy w jaki sposób przekazywać dane między żądaniami, zobaczmy jak to by wyglądało w praktyce.

(pseudokod)

[PHP]
$forms = array(/* tablica obiektów formularzy dla poszczególnych stron*/);
 
if(/*wysłano formularz*/)
{
  $page = /*strona obecnego formularza, załóżmy że numerowanie zaczyna się od 0 */;
  $values = /*dane wysłane postem*/;
  $fail = null;//pierwszy formularz, który nie przeszedł walidacji
 
  //waliduj wszystkie formularze do ostatnio wysłanego
  for($i=0; $i<$page; $i++)
  {
    if(!$forms[$i]->isValid($values))
    {
      $fail = $forms[$i];
      break;
    }
  }
 
  //wystąpił błąd
  if($fail)
  {
    //wyświetl $i-ty formularz z komunikatami błędów
    //oraz poprawnie zweryfikowane formularze jako ukryte pola
  }
  else
  {
    if(/* wysłano i zweryfikowano formularze ze wszystkich stron */)
    {
      //zapisanie danych do bazy danych i przekierowanie
    }
  }
}
 
if(!$fail)
{
  //wyświetl obecny formularz
  echo $forms[$page];
  for($i=0; $i<$page; $i++)
  {
    //wyświetl poprzednie formularz jako ukryte pola formularzy
  }
}

W powyższym rozwiązaniu cała logika obsługi wielostronicowego formularza jest skumulowana w jednym miejscu. To znacznie lepsze rozwiązanie niż obróbka formularzy z kolejnych kroków w innej akcji kontrolera. Dzięki powyższemu rozwiązaniu dodawanie kolejnych formularzy nie stanowi problemu, należy jedynie do tablicy $forms dodać kolejny obiekt formularza (lub tablicę reprezentującą formularz?) na odpowiednim miejscu oraz ewentualnie zmienić kod wykonywany po weryfikacji wszystkich formularzy.

Pierwszy punkt z listy przedstawionej na początku artykułu został spełniony: sposób przetwarzania jest dosyć prosty, spójny i elastyczny. Pozostaje problem przenośności kodu.

Plugin do obsługi wielostronicowych formularzy dla symfony

Swego czasu napisałem plugin do obsługi wielostronicowych formularzy dla frameworku symfony. Jego główne zadania to rozdzielanie wartości parametrów, walidacja poszczególnych formularzy oraz ukrycie przed programistą problemu przenoszenia danych między żądaniami.

Tworzenie własnego wielostronicowego formularza.

[PHP]
class Form extends psPageableForm
{
  public function setup()
  {
    $this->addForm(new Form1());
	$this->addForm(new Form2());
	$this->addForm(new Form3());
 
	$this->setNameFormat('form[%s]');
  }
}

Jednym ze sposobów stworzenia wielostronicowego formularza jest nadpisanie klasy psPageableForm i w metodzie setup (lub configure) dodanie kolejnych formularzy.

Przetwarzanie formularza tego typu będzie zbliżone do tego zaprezentowanego na pierwszym listingu - algorytm jest niemalże ten sam, z tą różnicą, że część zadań wykonują klasy pluginu.

[PHP]
//kontroler
public function executeProcessForm(sfWebRequest $request)
{
  $page = (int) $request->getParameter('step', 1);
  $form = $request->hasAttribute('form') ? $request->getAttribute('form') : new Form();
  $form->setPage($page);
 
  if($request->isMethod('post'))
  {
    //jeśli ta metoda została wywołana po błędzie walidacji poprzedniego formularza
	//nie przeprowadzaj walidacji
    if($request->getAttribute('return') != 1){
      $form->bind($request->getParameter('form'));
      if(!$form->isValid()){
        //numer strony to numer pierwszego niepoprawnego formularza
        $page = $form->getFirstInvalidForm()->getOption('page');
        $request->setParameter('step', $page);
 
        //utawić atrybuty żądania, aby przekazać zwalidowany formularz
        $request->setAttribute('return', 1);
        $request->setAttribute('form', $form);
 
        //wywołanie rekurencyjne akcji aby wyświetlić formularz
        //który nie przeszedł walidacji
        return $this->executeProcessForm($request);
 
      //zweryfikowano ostatni formularz
      }elseif($page > $form->getPages()){        
        //zapisanie danych do bazy
        $this->redirect(/*przekierowanie*/);
      }
    }
  }
  else
  {
    $form->setPage(1);
  }
 
  $this->form = $form;
}
 
//widok
echo $form->getCurrentForm();
//wyświetlenie ukrytych pól formularza
echo $form->persist();

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Ostatnio zetknąłem się z problemem wspólnych partiali dla wszystkich aplikacji w projekcie Symfony (dokładnie frontend i backend). Dokładniej, to te partiale były templatkami mailowymi, wysyłanymi zarówno przy zdarzeniach wygenerowanych w frontendzie jak i w panelu administracyjnym. Jako, że ponad wszystko cenię zasadę DRY (Don’t Repeat Yourself, czyli Nie Powtarzaj Się), chciałem, aby moje templatki były [...]

Propel generators are very useful tool, they automate creating of most common CRUD modules. However default theme have serial issues. Mostly, html forms are based on tables and list is not a sfPropelPager.

But there is an easy way to make your own theme based on symfony default. You can find it into sf_pear_dir/data/generator/sfPropelModule/default and add/modify whatever you want. To use it in your app just putt it into sf_project_dir/data/geneator/sfPropelModule directory.

Then using symfony console script use “theme” argument:

empathon@aden ~/workspace/example $ symfony propel:generate-module backend author Author --with-show --theme=clean

I have create my own custom theme with forms on divs, pager, flash messege on delete and create/edit. You can download it here.

Udpate: Few errors fixed.

That was tricky. I hope it will help somebody.

<?php
class SomeForm extends sfForm
{
	//..
 
	/**
	 * Return array of current errors
	 *
	 * @return array
	 */
	public function getErrorsArray()
	{
		$errors = $embedded_forms_name = array();
		foreach($this->getEmbeddedForms() as $embedded_form){
			$embedded_forms_name[] = $embedded_form->getName();
		}
		foreach($this as $field){
			if($field->hasError())
			{
				if(in_array($field->getName(), $embedded_forms_name)){
					foreach($field as $field_embedded){
						if($field_embedded->hasError()) $errors[$field->getName().'_'.$field_embedded->getName()] = $field_embedded->getError()->__toString();
					}
				} else {
					$errors[$field->getName()] = $field->getError()->__toString();
				}
			}
		}
		return $errors;
	}
}

For embedded forms it return embedded form name plus field name as a key. You got an idea ;-) It should be standard feature IMHO.

Update: Of course there is a easier way if you don’t have embedded forms:

//...
foreach ($this as $field) {
	$field->hasError() ? $errors[$field->getName()] = $field->getError()__toString() : null;
}

or

//...
foreach ($this->getErrorSchema()->getErrors() as $name => $error) {
	$errors[$name] = $error->getMessageFormat();
}