A null object mintáról sok helyen lehet olvasni. Alapvetően arról van szó, hogy abban az esetben, amikor egy objektum példányt kellene kapnod (mondjuk egy factory-tól), de az a feltételeknek megfelelő objektumot nem tud biztosítani, akkor nem null-t ad vissza, hanem egy úgynevezett null objektumot, amely típusában, viselkedésében megfelel egy “rendes” objektumnak.

A minta előnye, hogy nem kell folyamatosan vizsgálnunk a kapott értéket (null-e vagy objektum példány), egyszerűen csak használjuk. Hogy mire is jó, arra lássunk egy példát.

Tegyük fel, hogy van egy galériánk, amelyben (mily meglepő) képek találhatók. A galériának van egy kiemelt képe, amellyel megjelenik az oldalon. Feladat: hogyan tudjuk egyszerűen elérni, hogy azok a galériák, amelyeknek nincs kiemelt képe, egy “no-image.jpg”-et jelenítsenek meg?

Kezdjük az elején. A sémával.

Gallery:
  tableName: gallery
  columns:
    id:
      type: integer
      unsigned: true
      notnull: true
      primary: true
      autoincrement: true
    name:
      type: string(200)
    preview_image_id:
      type: integer
      unsigned: true
      notnull: true
  relations:
    PreviewImage:
      local: preview_image_id
      foreign: id
      type: one
      class: Image
Image:
  tableName: picture
  columns:
    id:
      type: integer
      unsigned: true
      notnull: true
      primary: true
      autoincrement: true
    gallery_id:
      type: integer
      unsigned: true
      notnull: true
    file:
      type: string(255)
    title:
      type: string(255)
  relations:
    Gallery:
      local: gallery_id
      foreign: id
      foreignAlias: Images
      onDelete: CASCADE

Ezzel a sémával már működni fog a galéria. Mint látható, a galéria tartalmaz egy preview_image_id mezőt, amely az előképre hivatkozás (ennek a mezőnek a kezelése a fejlesztőre hárul, általában egy, a galériába feltöltött képek közül). Mi történik akkor, ha most megprólájuk megjeleníteni az előképet?

Mindjárt meglátjuk, de előbb írjunk egy kis kódot. Készítsünk egy egyszerű API-t a képek kezeléséhez.

class Image extends BaseImage
{
  const TYPE_ORIGINAL = 1;
  const TYPE_THUMBNAIL = 2;

  // ...
  public function getImageName($type = self::TYPE_ORIGINAL)
  {
    $info = pathinfo($this->file);
    $names = array(
      self::TYPE_ORIGINAL => $this->file,
      self::TYPE_THUMBNAIL => $info['filename'].'_thumb.'.$info['extension'],
    );

    if (!isset($names[$type]))
    {
      throw new InvalidArgumentException();
    }

    return $names[$type];
  }

  public function getImagePath($absolute = true)
  {
    $path = '/uploads/images';
    $absolute_path = sfConfig::get('sf_web_dir').$path;

    if (!file_exists($absolute_path))
    {
      mkdir($absolute_path, 0777, true);
      chmod($absolute_path, 0777);
    }

    return $absolute ? $absolute_path : $path;
  }

  public function getImageFile($type = self::TYPE_ORIGINAL, $absolute = false)
  {
    return $this->getImagePath($absolute).'/'.$this->getImageFile($type);
  }
  // ...
}

Szóval mi történik, ha megpróbáljuk megjeleníteni az előképet?

<img src="<? echo $gallery->PreviewImage->getImageFile(); ?>" />

Hát az attól függ Ha van előkép, akkor megjelenik. Ha nincs, akkor viszont egy fatal error a jutalmunk. Tehát meg kell vizsgálnunk, hogy létezik-e az előkép. Sokkal kényelmesebb lenne, ha előkép beállítás nélkül is egy Image objektumot kapnánk (null object), amelyen meghívva a getImageFile() metódust, az alapértelmezett képet jelenítené meg.

Ehhez két dolog szükséges:

1. a doctrine, beállítás nélkül is egy Image példányt adjon
2. file megadás nélkül az alapértelmezett képet adja vissza

Az első pont könnyen teljesíthető. Változtassunk a sémán. A Gallery preview_image_id mezőjéről vegyük le a notnull előírást. Ekkor a doctrine egy frissen létrehozott Image példányt ad (roppant kellemes működés).

A második ponthoz kicsit át kell írni két metódust: getImageName(), getImageFile().

class Image extends BaseImage
{
  // ...
  public function getImageName($type = self::TYPE_ORIGINAL)
  {
    if ($this->file)
    {
      $info = pathinfo($this->file);
      $names = array(
        self::TYPE_ORIGINAL => $this->file,
        self::TYPE_THUMBNAIL => $info['filename'].'_thumb.'.$info['extension'],
      );
    }
    else
    {
      $names = array(
        self::TYPE_ORIGINAL => '/images/no_image.jpg',
        self::TYPE_THUMBNAIL => '/images/no_image_thumb.jpg',
      );
    }

    if (!isset($names[$type]))
    {
      throw new InvalidArgumentException();
    }

    return $names[$type];
  }

  public function getImageFile($type = self::TYPE_ORIGINAL, $absolute = false)
  {
    if (!$this->file)
    {
      return $this->getImageName($type);
    }
    return $this->getImagePath($absolute).'/'.$this->getImageFile($type);
  }
  // ...
}

Még egyszer kiemelném a Doctrine azon viselkedését, hogy az idegenkulcsról ha eltávolítjuk a notnull előírást, akkor a kapcsolt model lekérésekor nem null-t, hanem üres objektumot kapunk. A modelhez hozzáadott kód nagy előnye, hogy több képet szolgáltató objektum esetén alkalmazva egységes felületet kapunk. Emellett a getImagePath() nagyszerűen használható a feltöltő form validatorának path opciójaként.

Úgy gondolom ennyi. Várom a véleményeket, kritikákat

Korábban gondolkoztam rajta, hogy készítek egy írást a symfony eseménykezeléséről, összefoglalva, hogy melyik eseményt ki váltja mi és milyen listenerek vannak alapból. Aztán, ahogy telt az idő nem írtam semmit, illetve kijött a reference book, amelyben külön fejezetet szenteltek az események összefoglalásának.

Van néhány esemény, aminek nem szentelnek túl nagy figyelmet, pedig roppant hasznosak tudnak lenni. Ezek az admin genertároban találhatók:

• admin.pre_execute: minden admin action preExecute() metódusának végén értesít ki. Speciel ennek még nem láttam hasznát.
• admin.save_object: minden (admin generátor oldalon végzett) objektum mentés után értesíŧ ki. Nagyon hasznos minden olyan tevékenység elvégzésére, amely nem kötődik szorosan a modell osztályhoz, de meg kell történnie mentéskor (pl. cache ürítés, lucene index frissítés, …).
• admin.delete_object: minden (admin generátor oldalon végzett) objektum törlés előtt értesít ki. Hasonló előnyökkel kecsegtet, mint a mentésnél láttuk.

Az új ubuntuban problémáid adódhatnak, ha a PEAR-ben csomagot akarsz telepíteni vagy frissíteni (pl symfony-t ).

Ennek megoldásáról volt szó nemrég a magyar symfony google csoportban. Halászvári Gábor bug-reportja pedig itt.

Szerettem volna feltelepíteni néhány pecl csomagot, de folyamatosan a következő hibaüzenetet kaptam:

pecl.php.net is using a unsupported protocal – This should never happen.
install failed

Egy gyors keresés után meg is találtam a megoldást.

A megoldás röviden: törölni kell a meglévő csatornákat és frissíteni egyet.

cd `pear config-get php_dir`
mv .channels .channels-broken
pear update-channels

Konfiguráció: ubuntu 9.04, zend server ce, php 5.2.10

Érdemes erre a widgetre odafigyelni, különben nem várt meglepetésben lesz részed. A textareaban megjelenő szöveget illik escapelni, erre tökéletes is lenne a htmlspecialchars függvény. Csakhogy a symfony nem pontosan ezt csinálja. Az sfWidgetFormTextarea::render() kicsit megpróbál tovább menni. A form framework jó pár widgetben használja az sfWidget::escapeOnce() metódust, itt azonban ez igen veszélyes.

A kedves olvasóra bízom, hogy mi lesz az alábbi szöveggel, miután kétszer egymás után postolja az egy formon.

<p>ez itt egy bekezdes</p> &lt;script&gt;alert(&quot;aaa&quot;);&lt;/script&gt;

Miután sikeresen átálltunk 4-es swiftre komoly teljesítmény problémát vettünk észre. Nevezetesen: a swift 3 quoted-printable encodinggal időnként bugzott, ezt a 4-esben javitották, viszont az kódolást végző io stream teljesitménye elég siralmasra sikerült: kb 4x lassabb, mint swift 3 esetén.

A probléma ismert a fejlesztők előtt is, a 4.1.0-ben ezt az alrendszert teljesen újraírják. További hasznos olvasmány lehet a témában a problémára vonatkozó ticket.

Jelenleg még senkinek sem javaslom az átállást, aki nagyobb mennyiségű levélküldésre szeretné használni.

Frissítettem a Swift mailer leírásom. Immár a 4.x verziókhoz is elérhető

Megtaláltam a legjobb megfogalmazását a problémámnak.

A probléma

Symfony 1.0 admin generator alatta a lista nézet szűrése nagyon egyszerűen volt megoldva: az űrlapon megadott paraméterek GET-ként közlekedtek, maga a szűrés alkalmazása is a list actionben volt implementálva. Így máshonnan is könnyen használható volt, saját magunk által készített egyedi URLben is. Ez az új admin generator alatt most nem működik. Legalább is egyből nem, de mint látni fogjuk könnyen szóra bírható.

Az ok

A symfony 1.2 admin generator alatt a szűrés sfFormFilter alapú űrlapokkal van megoldva. Ez alapértelmezetten egyedi name formattal érkezik (model_neve_filters[%s]) és még a csrf védelem is be van kapcsolva. Emellett külön action (filter) készült a szűrés alkalmazásához.

A megoldás

Tehát 3 dolgot kell megoldanunk:

1. a filter actionnel nem tudunk mit kezdeni, a linkeket át kell írni
2. a csrf védelem kikapcsolása: a konstruktor felül kell írni, a harmadik paraméteren átadott $CSRFSecret paraméter helyett false értékkel kell meghívni a szülőt.
3. a name format paramétert át kell írni sima filters[%s]re.

Ezt megtehetjük az egyes filter form osztályokra, de alkalmazhatjuk egységesen a szülőben (BaseFormFilterDoctrine) megvalósítva is.

abstract class BaseFormFilterDoctrine extends sfFormFilterDoctrine
{
  public function __construct($defaults = array(), $options = array(), $CSRFSecret = null)
  {
    parent::__construct($defaults, $options, false);
  }

  public function setup()
  {
    $this->widgetSchema->setNameFormat('filters[%s]');
  }
}

Idén száz éves a magyar repülőgépmodellezés. Ennek alkalmából kiállítás nyílt a Közlekedési Múzeumban. Egy kis ízelítő