Idea Phoca Cart

H13 napsal: u CSV, nevím, jestli např. použít: id_produktu;id_kategorií;další_pložky:

1;1,2;jmeno_napr;

tedy oddělovat hodnoty pomocí středníku a tam, kde má položka více hodnot, použít čárku?

Čárku bych nepoužíval, je to poměrně běžný znak, který se v názvu kategorie může klidně objevit. Myslím, že se docela běžně používá svislá čára |

I ten středník v CSV může být problematický, ideálně by tam měly být ještě kolem hodnot uvozovky. V CSV ale stejně bude problém např. s exportem popisů - jak to bude víc řádek, tak CSV už moc nepomůže. Jedině to zas nahrazovat např. za \n

Pokud to bude klasické view (nebo třeba layout), umožňilo by to případné jednoduché změny v rámci override v šabloně - každý by si to pak mohl uzpůsobit dle potřeb.

Bong
Děkuji
Cony
Pokud to bude klasické view (nebo třeba layout), umožňilo by to případné jednoduché změny v rámci override v šabloně - každý by si to pak mohl uzpůsobit dle potřeb.

Teď jde o to, jestli to má být view, nebo prostě rovnou soubor ke stažení. View už je např. XML Feed.

Teoreticky to může být i kombinace, pomocí layoutu zobrazit a případně využít toto pro uložení souboru (tedy - získání dat z databáze, projet je foreachem v layouts (možnost přepisu) a poté buď zobrazit nebo poslat do prohlížeče jako soubor k uložení.

Těcho možností je víc - použít XML, CSV, nějakej univerzální formát (což asi nepůjde), nebo použít podobné funkce jako jsou v XML feedu (tedy, definovat si vlastní názvy jednotlivých "tagů" v XML)

Záleží na tom, k čemu se to bude používat - jestli jen na import/export v komponentě nebo spíš jako něco rychlýho pro zadávání produktů



Osobně nevidím důvod pro např. zálohování v XML nebo CSV, když máme SQL (pro mě osobně mnohem přehlednější a čitelnější), pokud někdo potřebuje exportovat kvůli nějakému externímu systému, pak stejně musí použít pole definovaný v tom externím systému - takto funguje např. XML feed - dají se nazvat "tagy" XML pro jendotlivé služby.

Takže já osobně vidím funkci importu/exportu spíš v tom, že si někdo zadá rychle produkty v Excelu/Calcu a ty rychle importuje nebo případně rychle edituje. Takový soubor je pak ale použitelný jen pro import/export, těžko se bude používat někde jinde (v aplikaci třetií strany - kvůli formátu nebo posloupnosti položek) :idea:

H13 napsal: Teoreticky to může být i kombinace, pomocí layoutu zobrazit a případně využít toto pro uložení souboru (tedy - získání dat z databáze, projet je foreachem v layouts (možnost přepisu) a poté buď zobrazit nebo poslat do prohlížeče jako soubor k uložení.

To s tím layout by bylo asi nejrozumnější - layout by byl jen pro jednu položku, pak by nemusel celý export viset v paměti.
Kdyby se navíc layout pojmenovali podle typu souboru pak přidání nového formátu by bylo jen v šabloně přidat nový soubor layout, dal by se tak řešit i případný formát pro konkrétní SW.

H13 napsal: Takže já osobně vidím funkci importu/exportu spíš v tom, že si někdo zadá rychle produkty v Excelu/Calcu a ty rychle importuje nebo případně rychle edituje. Takový soubor je pak ale použitelný jen pro import/export, těžko se bude používat někde jinde (v aplikaci třetií strany - kvůli formátu nebo posloupnosti položek) :idea:

Určitě, to je alespoň z mého úhlu pohledu nejdůležitější, ne-li jediná aplikace - rychlá editace produktů. Dovedl bych si představit i využití na import a aktualizaci položek z nějakého skladového SW - samozřejmě pokud by dodržel pořadí položek.

Další otázkou je, jak je to s ukládáním ID např. kategorie.

Např. produkt je v kategoriích 1. Alfa, 2. Beta, 3. Gama

Nejjednodušší je uložit jako ;1|2|3; - to je optimální pro import a export
Pro uživatele by zase bylo dobrý ukládat s názvem: ;1:Alfa|2:Beta|3:Gama; což mu dává přehled o tom, v jaké kategorii co a jak je, ale pro zpracování je to hodně náročné - zbytečně se do zpracování bere tabulka kategorii a navíc může nastat problém se zpracováním znaku mezi číslem kategorie a názvem - zase by to musel být znak, co se nepoužívá v názvu kategorie :idea:

ID by pro zpracování, ale stejně by tam měla být nějaká základní kontrola při importu, že se neimportují neexistující ID skupin.
Navíc, pokud se bavíme o přenosu dat z externího systému, ID mezi těmi dvěma systémy asi nebudou souhlasit.
A že by uživatel zadával ID někde v excelu si už nedokážu vůbec představit.

Opět, když si vezmu za vzor feedy pro heureku apod. tak kategorie se tam zadávají s celým stromem a jen pomocí názvů. To je sice počítačově strašná varianta, ale uživatelsky asi jediná přehledná.

Jinak pokud by bylo ID před dvojtečkou, tak nějaký spec. znak není přece třeba řešit. Prostě by se za ID považovala všechny číslice 0-9 před první dvojtečkou. Pokud by tam číslice nebyla tak je to hámotina a ne ID, a netřeba se tím zabývat...