Baobaz Blog

I na tym nie koniec, bo rekrutacja wciąż trwa!

Istnieje wiele poradników w których napisano jak skonfigurować Magento do pracy z wieloma sklepami, tak by różne domeny wskazywały na wybrane sklepy. Począwszy od wydań Magento CE 1.4.0.0-alpha2 i Magento EE 1.6.0.0 stało się to wiele prostsze w wykonaniu.

Magento ewoluuje

Rozwiązania stosowane w poprzednich wersjach wymagały od programisty modyfikacji zawartości pliku index.php, jeżeli chciał obsłużyć wyświetlanie różnych sklepów zależnie od domeny. Nowy plik index.php zawiera następujący kod:

Sprawdza on dwie zmienne środowiskowe i używa ich uruchamiając Magento. Jakie możliwości to nam daje? Możemy teraz ustawić który sklep ma działać pod daną domeną bezpośrednio w definicji wirtualnego hosta a nawet w pliku .htaccess.

Rozwiązanie z użyciem VirtualHost

Aby czerpać z korzyści powyższego kawałka kodu wystarczy dodać następujące linie wewnątrz definicji wirtualnego hosta:

Rozwiązanie z użyciem .htaccess

Jeżeli nie masz dostępu do definicji wirtualnego hosta, możesz wciąż wykorzystać w tym celu plik .htaccess, umieszczając w nim następujące linie:

Gdzie .*yourhost.* jest wyrażeniem regularnym wychwutującym domenę dla której chcesz ustawić zmienną środowiskową.

Masz zatem teraz możliwość skonfigurować Magento do pracy z wieloma sklepami bez konieczności mieszania w rdzeniu Magento. Powodzenia.

Gdy już pomówiliśmy o opcjach "Panelu Admina" w Magento (Opcje backoffice (Panelu Admina) w Magento - [Część 1]), przejdźmy wreszcie do praktyki. W poprzedniej części pojawiła się informacja o tym, że możesz dodać do menu własne elementy. Ta możliwość przydaje się, gdy dopisujesz moduły i chcesz nimi zarządzać - oczywiście możesz stworzyć nowy element menu po to, by zmieniać ustawienia już istniejących funkcjonalności. Zatem - do dzieła ;)

Przede wszystki potrzebujemy nowego modułu. Możesz skorzystać z tego, który dołączyłam, to moduł napisany specjalnie do zaprezentowania tego, co opiszę. Będzie wyświetlał aktualny czas na podstawie wybranego przez ciebie formatu. Powinien być poprawnym argumentem funkcji date() w PHP.

Dodanie elementu następuje w pliku config.xml. Potrzebujemy d tego następujących linii:

Ten kod utworzy element menu o tytule Set Time Format z podmenu Set It!, które będzie prowadzić do modułu o identyfikatorze example, kontrolera index, akcji index. To wszystko, co jest potrzebne. Sprawdź efekt w Panelu Admina - 'Set Time Format' powinno pojawić się pomiędzy Catalog i Customers. Jeśli tak nie jest - wyczyść cache.

Dane przechowuję wspólnie z ustawieniami konfiguracyjnymi Magento. Nie jest to dobre rozwiązanie w przypadku profesjonalnego projektu, jednak zdecydowałam się na nie, aby nie tworzyć więcej kodu, niż było to konieczne.

Element zarządzający ustawieniami można dodać również na stronie System->Configuration. Wymaga to nieco innego podejścia, które zostanie opisane w części 3.

Jedną z najlepszych rzeczy w magento jest możliwość łatwego dodawania nowych wersji językowych do strony. Robi się to używając plików CSV. Dla każdego języka mamy jeden plik na jeden moduł. Dla najpopularniejszych języków gotowe tłumaczenia dostępne są za darmo jako moduły Magento w systemie magento connect.

A co jeśli chcemy zmienić jakieś tłumaczenie i nie zgubić zmian po uaktualnieniu magento i modułów z tłumaczeniami? Lub jeśli chcemy mieć jakieś teksty tłumaczone poza kontekstem jednego modułu? Lub po prostu mieć wykaz wszystkich tekstów które zostały przez nas dodane a nie ma ich w "gołym" magento? Możemy stworzyć swój własny prosty moduł tłumaczeń.

Wystarczy stworzyć 2 pliki:

• etc/config.xml
  
   <?xml version="1.0"?>
   <config>
          <modules>
                  <baobaz_translations>
                          <version>0.1.0</version>
                  </baobaz_translations>
          </modules>
         
          <global>
                  <helpers>
      <translations>
      <class>Baobaz_Translations_Helper</class>
      </translations>
      </helpers>
          </global>
         
          <frontend>
      <translate>
      <modules>
                                  <baobaz_translations>
                                          <files>
                                                  <default>Baobaz_Translations.csv</default>
                                          </files>
                                  </baobaz_translations>
                          </modules>
      </translate>
      </frontend>
   
   </config>
   
• oraz helper/data.php:
  
  class Baobaz_Translations_Helper_Data extends Mage_Core_Helper_Abstract
  {
  
  }

I to wszystko... Moduł trzeba włączyć (w etc/modules) i wszystko będzie działać.

w app/locale/fr_fr/ tworzymy plik Baobaz_Translations.csv a w nim wstawiamy wszystkie przetłumaczone teksty.

Następnie wszędzie w projekcie - niezależnie od tego czy jest to szablon, blok czy kontroler możemy użyć składni:

Tak, to jesttak proste.

Jak wiemy, standardowa instalacja Magento dostarczana jest z javascriptową biblioteką Prototype. Razem z odpowiedzialną za efekty script.aculo.us składa się na potężne narzędzie ułatwiające tworzenie różnego rodzaju funkcjonalności działających po stronie przeglądarki. Na tym jednak nie koniec - Prototype dostarcza również framework do obsługi modnej i przydatnej technologii Ajax, dzięki czemu tworzenie ajaxowych zapytań staje się niebywale proste. Funkcjonalność Prototype'a wykorzystywana jest w wielu szablonach Magento, między innymi do pokazywania/ukrywania bloków zależnie od wyboru użytkownika, tudzież do wyświetlania komunikatów o błędzie z eleganckim efektem "fade".

Jednakże nie jest to jedyna javascriptowa biblioteka oferująca tak przydatny zestaw funkcji. Wśród innych popularnych bibliotek wyróżnić można jQuery - niewielką objętościowo (skompresowana zajmuje 19KB), prostą w użyciu i do tego, przyznaję, moją ulubioną. Stworzona w 2006, błyskawicznie zyskała sobie grono użytkowników, którzy opracowali do niej mnóstwo rozszerzających jej funkcjonalność wtyczek.

Zastanówmy się jednak, czy to dobry pomysł by wykorzystywać obie te biblioteki jednocześnie w jednym projekcie Magento? Moim zdaniem nie, przynajmniej w większości przypadków. Dlaczego? Jest kilka głównych powodów:

• Obydwie dostarczają podobną funkcjonalność, w związku z czym praktycznie nie ma rzeczy, którą da się osiągnąć w jednej, a w drugiej byłoby to niemożliwe
• Więcej dołączonych plików .js oznacza wolniejsze ładowanie się stron i słabszą wydajność
• Biblioteki te używają czasem tej samej notacji, co może prowadzić do konfliktów

Niemniej jednak w pewnych przypadkach dołączenie jQuery do funkcjonalności sklepu w Magento może być konieczne. Na przykład w sytuacji gdy potrzebujemy biblioteki dostarczającej nam konkretnej funkcjonalności, a biblioteka ta jest stworzona jako wtyczka do jQuery. Jak więc sprawić by Prototype i jQuery działały razem bez żadnych konfliktów?

Po pierwsze, należy ściągnąć najnowszą wersję jQuery (póki co ostatnia wersja to 1.3.2) i zapisać ją w folderze /js/jquery. Następnie trzeba dołączyć ją do wszystkich stron Magento - najbardziej logicznym sposobem, by tego dokonać, jest wstawienie poniższego kodu w pliku /app/design/frontend/.../.../layout/page.xml, w sekcji <block type="page/html_head">:

Nadeszła pora na poradzenie sobie z konfliktami z Prototype - obie biblioteki używają notacji $ (w jQuery jest to skrót do jQuery, podczas gdy w Prototype służy ona za alias do funkcji getElementById. Na szczęście twórcy jQuery wpadli na to, by stworzyć mechanizm do przeciążania funkcji $: jQuery.noConflict(). Można zatem umieścić poniższą linijkę na końcu pliku jquery-1.3.2.min.js:

Od tej chwili należy używać funkcji $j wszędzie tam, gdzie do tej pory używana była $ (cały czas można również stosować jQuery). Pamiętajcie więc o zastąpieniu wszystkich wystąpień funkcji $ we wtyczkach do jQuery (o ile nie zostało to już domyślnie zaimplementowane przez autorów wtyczki).

W tym miejscu normalnie zakończylibyśmy nasze rozważania, gdyby nie jedna przeglądarka, która wciąż, mimo wprowadzonych przez nas rozwiązań, ma problemy ze wspólnym działaniem Prototype i jQuery. I nie, nie jest to Internet Explorer ;) Co zaskakujące, to Firefox 2. Przeglądarka ta wyrzuca mało zrozumiałe błędy, po których przestaje wykonywać załączony JavaScript. Oczywiście, od dawna są już dostępne nowsze wersje Firefoxa, w których po tym problemie nie ma już śladu, ale ciągle jest przecież jakaś drobna część internautów, którzy używają Firefoxa 2 i być może koniecznie chcą wydać pieniądze w Waszym sklepie ;)

Istnieje na szczęście prosty sposób na rozwiązanie tego problemu: trzeba umieścić instrukcję dołączającą jQuery przed dołączeniem Prototype. A zatem należy postąpić następująco w pliku page.xml:

Od tej chwili o wszelkich konfliktach możecie zapomnieć, a owe dwie wspaniałe biblioteki będą ze sobą idealnie współpracowały.

Tłumaczenia pomiędzy językami są całkiem proste do zrealizowania w Magento. Dla doświadczonego programisty PHP, który pracował już z frameworkami, nie ma nawet o czym wspominać. Jednak osoba, która stawia pierwsze kroki w budowaniu wielojęzycznej aplikacji. może potrzebować kilku słów wprowadzenia. Teksty, które przeznaczone są do tłumaczenia, przechowywane są w plikach CSV, w katalogu /app/locale/[kod_jezyka]. Część ścieżki oznaczona jako [kod_jezyka] to na przykład 'pl_PL'.

Przyjrzyjmy się teraz zawartości któregoś z tych plików - każdy z nich ma tę samą strukturę. Linie w każdym pliku zawierają dwa teksty oddzielone przecinkiem: jeden w twoim domyślnym języku i jeden w języku docelowym. Aby móc używać tych plików - nazywanych też słownikami - trzeba zadeklarować je w pliku konfiguracyjnym danego modułu (config.xml). Poniższy kod musi zostać umieszczony wewnątrz znacznika frontendu lub admina - zależnie od tego, dla której części sklepu przeznaczone są tłumaczenia.

To wszystko ;) Teraz, aby użyć tekstu, który ma zostać przetłumaczony, napisz:

Magento sprawdzi czy w słownikach znajduje się tekst o treści 'tekst do przetłumaczenia' i wyświetli odpowiadające mu tłumaczenie w języku aktualnego sklepu.

Jeśli rozpoczynasz dopiero swoją przygodę z Magento, możesz być przerażony ilością opcji, którą oferuje ci backoffice (nazywany też "Panelem Admina"). Po typowej instalacji dostępne są: Dashboard, Sales, Catalog, Customers, Promotions, Newsletter, CMS, Reports, and System (jeśli nie wszystkie z nich widzisz, upewnij się, że jesteś zalogowany z uprawnieniami administratora). W dalszych częściach omówimy też dodawanie własnych elementów menu. Wszystkie z tych elementów, które widzisz, zawierają podmenu - wyjątkiem jest tylko Dashboard. Czas, aby przyjrzeć się niektórym z nich.

Dashboard to strona domyślna "Panelu Admina". Możesz na niej zobaczyć zestawienie najważniejszych informacji na temat wybranego sklepu - dane najnowszych zamównień, najnowsze zamówienia z wybranego zakresu czasu, kwotę zamówień z wybranego zakresu czasu, najlepiej sprzedające się produkty, produkty najczęściej oglądane, nowych klientów... Jest to zatem właśnie to, czego można się spodziewać po domyślnej stronie "Panelu Admina". Sales umożliwia ci zarządzanie zamówieniami (Orders), fakturami (Invoices), dostawami (Shipments) i podatkami nakładanymi na produkty (Tax). Właśnie tu możesz przyjrzeć się lub modyfikować zamówienia, składane przez twoich klientów. Możesz je przeglądać, odwoływać, wstrzymywać i drukować. Czego trudniej się domyślić, ta sekcja zawiera także możliwość ustalenia warunków sprzedaży (Terms and Conditions).

Kolejny element menu to System. Zawiera kilka opcji wartych zapamiętania. Tools pozwoli ci na wykonanie kopii zapasowej. Chyba nie trzeba nikogo przekonywać, że warto korzystać z tej opcji ;) Jest tu też Cache Management, czyli zarządzanie pamięcią podręczną. A na końcu - konfiguracja (Configuration). Zajrzyj do zakładki określającej wygląd twojego sklepu (Design). Tutaj wybierasz skórkę dla sklepu(skin), rozmieszczenie elementów (layout) i domyślny motyw graficzny (theme). Magento wybierze motyw domyślny wtedy, gdy nie znajdzie tego, który wybierzesz. Możesz też wybrać znak wodny dla obrazków używanych w sklepie. No i w końcu - ustawienie, którego używam najczęściej.

Zajrzyj do zakładki Developer, wewnątrz Configuration. Wybierz swój sklep jako zakres konfiguracyjny (Current Configuration Scope) w polu po lewej. Zauważysz, że sekcja Debug będzie teraz zawierać pola Wskazówki dla ścieżek szablonów (Template Path Hints), and Dodaj do wskazówek nazwę bloku (Add Block Names to Hints). Odznacz Użyj strony web(Use website) i ustaw oba na Yes. Teraz wróć do frontoffice i odśwież stronę (upewnij się, że znajdujesz się w tym sklepie, który wybrałeś w Configuration Scope e Panelu Admina). Otrzymasz nazwy szablonów (template'ów), użytych do wyświetlenia strony, razem z odpowiadającymi im nazwami bloków. Przerywane linie wyznaczają granice szablonów. Wierz mi - warto zapamiętać tę opcję ;)

System szablonów w Magento w prosty sposób umożliwia tworzenie własnego kodu html/css, realizującego założenia projektu graficznego. Jednakże w wielu przypadkach, o ile to możliwe, właściwsze byłoby wykorzystanie domyślnych szablonów Magento. W ten sposób oszczędzić można dużo czasu poświęconego na integrację nowej struktury kodu html z funkcjonalnością sklepu internetowego Magento.

Dla przykładu, rzućmy okiem na następującą lokalizację w standardowej strukturze plików Magento: app\design\frontend\default\default\template\page. W tym miejscu znajdziemy szablony opisujące najbardziej podstawową i ogólną strukturę strony: 1column.phtml, 2colums-left.phtml, 2colums-right.phtml lub 3colums.phtml. Każdy z tych szablonów zawiera niemal ten sam kod html (skupmy się na części znajdującej się wewnątrz sekcji 'body'):

Jedyna różnica pomiędzy tymi szablonami to część wewnątrz <div class=”middle-container”> - w tym miejscu zdefiniowany jest kod html odpowiedni dla konkretnego layoutu strony. Co jest jednak najbardziej istotne, szablony te powielają najczęściej stosowany sposób podziału struktury strony - na nagłówek, główną część i stopkę. Zatem w większości przypadków możemy wykorzystać powyższe domyślne szablony bez żadnych modyfikacji kodu html, wykorzystując jedynie style css, aby dostosować wygląd strony do wymagań projektu graficznego.

Jasną sprawą jest, że im bardziej szczegółowy szablon, tym mniejsza jest szansa wykorzystania go w niezmienionej formie, mimo to wciąż najszybszym sposobem będzie rozpoczęcie od domyślnego szablonu Magento i zmodyfikowania go tylko w takim zakresie, w jakim jest to konieczne.

Artykuł " Magento DataFlow - elastyczna wymiana danych" przedstawił globalny koncept frameworka wymiany danych zaimplementowanego w Magento. Dziś chciałbym napisać więcej o standardowych adapterach zaimplementowanych w module DataFlow.

1. Definicja adaptera

   Adaptery są odpowiedzialne za pobieranie danych z zewnętrznych źródeł albo ich zapisywania do tychże. W tym celu wszystkie adaptery implementują interfejs Mage_Dataflow_Model_Convert_Adapter_Interface, który zawiera dwie metody: load() i save(). Koncept wymiany danych przyjęty w module DataFlow wykorzystuje adaptery w 3 kontekstach:

   • by załadować dane ze źródła - używając metody load()
   • by zapisać dane do źródła - używając metody save()
   • by wykonać operacje na jednym przetwarzanym wierszu - gdy zdefiniowane jako para zmiennych adapter/metoda parsera

   W pierwszych dwóch kontekstach definicja xml adaptera wygląda następująco:

   <action method="load" type="dataflow/convert_adapter_io">
        ...
   </action>

   Tag action posiada dwa parametry: typ i metoda. Typ decyduje, która klasa adaptera będzie wykorzystana w danej akcji. Klasę definiujemy podając jej alias. Parametr metoda mówi, która metoda klasy adaptera zostanie wywołana przez akcję. Jak wspomniałem już wcześniej, domyślnie dostępne są dwie metody: load i save. Wewnątrz taga action definiujemy zmienne, które są parametrami wykorzystywanymi podczas wykonywania metody adaptera. Zmienne definiuje się tak jak w poniższym przykładzie:

    
   <action method="load" type="dataflow/convert_adapter_io">
      <var name="type">file</var>
      <var name="path">var/import</var>
      <var name="filename"><!--[CDATA[products.csv]]--></var>
      <var name="format"><!--[CDATA[csv]]--></var>
   </action>

2. Standardowe adaptery modułu Magento DataFlow

   Moduł DataFlow Magento zawiera kilka standardowych klas adapterów, które można znaleźć w katalogu app/code/core/Dataflow/Model/Convert/Adapter. Nie wszystkie z nich mają jednak zaimplementowane metody load() i save().

   W przypadku powszechnej czynności odczytywania danych z lub zapisu danych do pliku lokalnego lub zdalnego możesz wykorzystać adapter dataflow/convert_adapter_io (Mage_Dataflow_Model_Convert_Adapter_Io).

   Przedstawione poniżej zmienne pozwalają Ci zdefiniować plik lokalny/zdalny jako źródło danych:

   • type - definiuje typ źródła. Poprawne wartości to: file, ftp
   • path - definiuje ścieżkę względną do pliku
   • filename - definiuje nazwę pliku źródła
   • host - dla źródła ftp definiuje domenę ftp
   • port - dla źródła ftp definiuje port ftp (domyślnie 21)
   • user - dla źródła ftp definiuje nazwę użytkownika (domyślnie jeżeli nie podana zostanie inna wartość przyjmuje 'anonymous' dla zmiennej user i 'anonymous@noserver.com' dla zmiennej password
   • password - dla źródła ftp definiuje hasło użytkownika
   • timeout - dla źródła ftp definiuje maksymalny czas oczekiwania na połączenie (domyślnie 90)
   • file_mode - dla źródła ftp definiuje tryb odczytu pliku (domyślnie FTP_BINARY)
   • ssl - dla źródła ftp definiuje czy korzystać z połączenia ssl
   • passive - dla źródła ftp definiuje tryb połączenia z serwerem ftp (domyślnie false)

3. Adaptery encji klienta i produktu

   Dla najczęściej importowanych/eksportowanych encji - klienta i produktu - Magento dostarcza w standardzie adaptery: customer/convert_adapter_customer (Mage_Customer_Model_Convert_Adapter_Customer) i catalog/convert_adapter_product (Mage_Catalog_Model_Convert_Adapter_Product). Oba dziedziczą po Mage_Eav_Model_Convert_Adapter_Entity.

   By w najprostszy sposób załadować wszystkich klientów wybranego sklepu możesz użyć następującej definicji:

   <action type="customer/convert_adapter_customer" method="load">
       <var name="store">default</var>
   </action>

   Czasem możesz jednak chcieć załadować tylko wybranych użytkowników z bazy danych. By Ci w tym pomóc dostępny jest następujący zestaw zmiennych:

   • filter/firstname - by załadować tylko klientów, których imię zaczyna się od podanej wartości
   • filter/lastname - by załadować tylko klientów, których nazwisko zaczyna się od podanej wartości
   • filter/email - by załadować tylko klientów, których email zaczyna się od podanej wartości
   • filter/group - by załądować tylko klientów z wybranej grupy zdefiniowanej przez id
   • filter/adressType - by eksportować tylko wybrany typ adresu; poprawne wartości: both, default_billing, default_shipping
   • filter/telephone - by załadować tylko klientów, których numer telefonu zaczyna się od podanej wartości
   • filter/postcode - by załadować tylko klientów, których kod pocztowy zaczyna się od podanej wartości
   • filter/country - by załadować tylko klientów z kraju o podanym kodzie iso
   • filter/region - by załadować tylko klientów z wybranego regionu (dla USA wystarczy podać dwuliterowe kody stanów)
   • filter/created_at/from - by załadować tylko klientów stworzonych po podanej dacie
   • filter/created_at/to - by załadować tylko klientów stworzonych przed podaną datą

   Na przykład:

   <action type="customer/convert_adapter_customer" method="load">
       <var name="store"><![CDATA[0]]></var>
       <var name="filter/firstname"><![CDATA[a]]></var>
       <var name="filter/lastname"><![CDATA[a]]></var>
       <var name="filter/email"><![CDATA[a]]></var>
       <var name="filter/group"><![CDATA[1]]></var>
       <var name="filter/adressType"><![CDATA[default_billing]]></var>
       <var name="filter/telephone"><![CDATA[1]]></var>
       <var name="filter/postcode"><![CDATA[7]]></var>
       <var name="filter/country"><![CDATA[BS]]></var>
       <var name="filter/region"><![CDATA[WA]]></var>
       <var name="filter/created_at/from"><![CDATA[09/22/09]]></var>
       <var name="filter/created_at/to"><![CDATA[09/24/09]]></var>
   </action>

   W ten sam sposób możesz załadować i filtrować produkty z bazy danych, używając następujących zmiennych:

   • filter/name - by załadować tylko produkty, których nazwa zaczyna się podaną wartością
   • filter/sku - by załadować tylko produkty, których sku zaczyna się podaną wartością
   • filter/type - by załadować tylko produkty, których typ odpowiada zdefiniowanemu; poprawne wartości: simple, configurable, grouped, bundle, virtual, downloadable
   • filter/attribute_set - by załadować tylko produkty, których id zestawu atrybutów odpowiada podanej wartości
   • filter/price/from - by załadować tylko produkty, których cena jest nie mniejsza niż podana wartość
   • filter/price/to - by załadować tylko produkty, których cena jest nie większa niż podana wartość
   • filter/qty/from - by załadować tylko produkty, których ilość jest nie mniejsza niż podana wartość
   • filter/qty/to - by załadować tylko produkty, których cena jest nie większa niż podana wartość
   • filter/visibility - by załadować tylko produkty o zdefiniowanej w zmiennej widoczności
   • filter/status - by załadować tylko produkty o zdefiniowanym w zmiennej statusie

   Przykład:

   <action type="catalog/convert_adapter_product" method="load">
       <var name="store"><![CDATA[0]]></var>
       <var name="filter/name"><![CDATA[a]]></var>
       <var name="filter/sku"><![CDATA[1]]></var>
       <var name="filter/type"><![CDATA[simple]]></var>
       <var name="filter/attribute_set"><![CDATA[29]]></var>
       <var name="filter/price/from"><![CDATA[1]]></var>
       <var name="filter/price/to"><![CDATA[2]]></var>
       <var name="filter/qty/from"><![CDATA[1]]></var>
       <var name="filter/qty/to"><![CDATA[2]]></var>
       <var name="filter/visibility"><![CDATA[2]]></var>
       <var name="filter/status"><![CDATA[1]]></var>
   </action>

Wygląda to trochę przerażająco jeśli spojrzeć na konieczność używania wartości id, które musisz podać definiując filtry. Na szczęście dla tych dwóch encji - klientów i produktów - dostępny jest generator profili, który pozwala Ci zdefiniować filtr za pomocą prostego formularza.

W następnej części opiszę użycie parserów i adapterów w kontekście parserów.

Jedną z głównych funkcjonalności rozwiązań e-commerce jest możliwość dzielenia danych z systemem zarządzania sprzedażą offline. Magento czyni wymianę danych elastyczną i łatwą dzięki modułowi DataFlow.

Magento DataFlow to framework wymiany danych, którzy korzysta z czterech typów komponentów: adapter, parser, maper i walidator. W chwili obecnej walidatory nie zostały jeszcze zaimplementowane, ale zarezerwowano ten termin celem wykorzystania w przyszłości.

Proces wymiany danych zdefiniowany jest jako struktura XML i nazywany jest profilem. Magento udostpęnia prosty kreator generujący podstawowe profile importu/exportu działające na encjach produktów i użytkowników. Dostępny jest również zaawansowany menadżer profili dający możliwość zaawansowanym użytkowikom tworzyć profile o większym stopniu skomplikowania, w tym działające na innych encjach bądź obiektach.

Adaptery są odpowiedzialne za pobieranie danych z zewnętrznych źródeł oraz ich przetwarzanie i filtrowanie. Mogą być użyte na przykład do pobrania danych z: lokalnych lub zdalnych plików, web services, bazy danych i innych.

Na przykład aby załadować dane z pliku CSV należy wstawić strukturze XML definiującej profil następujący kod:

By załadować dane ze zdalnego pliku zlokalizowanego na serwerze FTP możemy użyć tego samego adaptera, ale z następującymi parametrami:

Parsery są odpowiedzialne za transformację danych z jednej postaci na drugą. Mogą być użyte na przykład do konwersji zawartości pliku CSV na dwuwymiarową tablicę, bądź w drugą stronę.

By przetworzyć zawartość pliku CSV na tablicę produktów w bazie danych można użyć następującego kodu:

Adapter zdefiniowany jako zmienna parserao nazwie <var name="adapter"> oraz metoda adaptera <var name="method"> są odpowiedzialne za przetworzenie załadowanych danych. W tym konkretnym przypadku parser przetwarza dane z foramatu pliku CSV na dwuwymiarową tablicę wywołując metodę parse adaptera.

Najprostszym sposobem dostosowania importu do swoich potrzeb jest napisanie własnego adaptera i podanie go jako zmienną w definicji parsera. W większości przypadków oznacza to konieczność nadpisania jednego z istniejących adapterów i napisania własnej metody przetwarzającej dane (w większości przypadków oznacza to nadpisanie metody saveRow())

Mapery są odpowiedzialne za zmianę wartości danych na inne. Znajdują zastosowanie w przypadku mapowania jednego pola na inne pole.

W przykładzie poniżej pole 'reference' ze źródła mapowane jest na pole 'sku' a zmienna '_only_specified' ustawiona na true inforumje, że importowane/exportowane będą tylko wymienione pola:

To tylko wierzchołek góry lodowej jaką są możliwości oferowane przez moduł DataFlow Magento. Wróć później by przeczytać o nich więcej.