Ponieważ mamy ostatnio okazję popracować z MagentoAPI postanowiliśmy również zamieścić kilka przydatnych informacji na ten temat.

Zaczynamy od podania dostępnych filtrów, które można wykorzystać filtrując dane z API:

Jako że na stronie dokumentacji API nie ma podanych tych informacji z całą pewnością sami również będziemy tutaj często zaglądać.

Przykład wykorzystania:

$server->call($sessionID, 'customer.list', array(array('email' => array('like' => 'jim%'))));

Tablice asocjacyjne w javascript różnią się znacząco od tablic liczbowych. Największą różnicę odczujemy w momencie gdy chcemy sprawdzić długość tablicy asocjacyjnej. Okaże się wtedy, że wywołanie:

alert(nazwa_tablicy.length);

zwróci wartość 0 niezależnie od tego ile elementów tablicy zdefiniowaliśmy.

Wywołanie typeof(nazwa_tablicy) na tablicy asocjacyjnej zwróci wartość ‘object’. Tablica asocjacyjna jest więc w javascript obiektem.

Jak zatem sprawdzić ilość elementów w tablicy asocjacyjnej.

Wystarczy wywołać następujący kod:

Object.keys(nazwa_tablicy).length

W efekcie otrzymamy ilość elementów tablicy.

Programując w javascript bardzo często zachodzi sprawdzenia czy zmienna której chcemy użyć została już zdefiniowana.

Ponieważ na stronach internetowych i forach bardzo często podaje się dużo różnych, nazwijmy to średnio skutecznych rozwiązań – podajemy jedyne skuteczne i prawidłowe.

if(typeof(nazwa_zmiennej)!=’undefined’){

alert(’zmienna nie została zdefiniowana’);

}

Jak widać nie porównujemy samej zmiennej a jedynie jej typ. Jeżeli zmienna nie została zdefiniowana zawsze otrzymamy typ ‘undefined’. Jeżeli zostanie zdefiniowana zawsze będzie to jedna z wartości:

• number
• string
• boolean
• object
• function

W ramach ciekawostki : typeof ( typeof ( nazwa_zmiennej ) ) zawsze zwróci typ string.

W tym krótkim artykule zaprezentujemy jak zdefiniować w symfony2 + doctrine2 indexy wielokolumnowe – zwykłe oraz unikalne.

Sprawa wydaje się być prosta i mogłaby zostać opisana w standardowej dokumentacji symfony2 – tak jednak nie jest i trzeba się troszkę namęczyć żeby takie informacje znaleźć. Skoro my już przez to przeszliśmy, dzielimy się tą wiedzą, abyście Wy już nie musieli na to tracić czasu.

Zatem – załóżmy że mamy Entity o definicji:


/**
* @ORM\Entity
* @ORM\Table(name="SitePage")
*/
class SitePage
{
/**
* @ORM\Id
* @ORM\Column(type="integer", nullable="false")
* @ORM\GeneratedValue(strategy="AUTO")
*/
protected $id;

/**
* @ORM\ManyToOne(targetEntity="Site", inversedBy="pages")
* @ORM\JoinColumn(name="idSite", referencedColumnName="id", onDelete="CASCADE")
*/
protected $site;
protected $idSite;

/**
* @ORM\Column(type="string",length="255", nullable="false")
*/
protected $name;

/**
*
* @ORM\Column(type="string",length="255", nullable="false")
*/
protected $slug;
}


Zależy nam na tym, aby kolumna slug wraz z kolumną idSite stanowiły index. Rozpatrzymy dwa przypadki:

1. index zwykły
2. index unikalny

W obu przypadkach musimy rozszerzyć definicję

@ORM\Table(name="SitePage")

W pierwszym przypadku (zwykły index) będzie to wyglądać w sposób następujący:

@ORM\Table(name="SitePage", indexes={@ORM\Index(name="index_site_page_slug_idx", columns={"idSite","slug"})})

Natomiast w drugim przypadku (index unikalny) będzie to wyglądać tak:

@ORM\Table(name="SitePage", uniqueConstraints={@ORM\Index(name="unique_site_page_slug_idx", columns={"idSite","slug"})})

Po odpowiedniej zmianie standardowo wywołujemy komendy odpowiedzialne za ponowne przegenerowanie Entity oraz update w bazie danych czyli:

php app/console doctrine:generate:entities Namespace

php app/console doctrine:schema:update --force

I to tyle – mam nadzieję, że uda nam się oszczędzić trochę Waszego czasu.