 |
|
|
|
|
| Autor | Wiadomość |
|---|---|
|
Napisane: 30.04.2010 [20:15]
|
|
|
dpacholczyk
Twórca tematu
zarejestrowany: 17.09.2008
Posty: 1072
|
Witam, zastanawia mnie jedna sprawa. Muszę tutaj posłużyć się jakimś przykładem bo problem jest dość złożony. Załóżmy, że mam magazyn różności. Mam tam samochody, telefony, jedzenie, komputery. No różne zupełnie nie związane ze sobą rzeczy. No i chce stworzyć katalog tych rzeczy na stronie. Więc szukam se fajnego rozszerzenia, ale nie ma żadnego które mogłoby obsłużyć tak zróżnicowane elementy. Trzeba stworzyć sobie takie rozszerzenie. I teraz sendo sprawy. Żeby to miało sens, każdy TYP (rodzaj przedmiotu) powinien być inaczej opisany. Czy jest możliwość, aby flexform był generowany różnie ? Tzn. jestem userem w BE. Dodaje sobię typ (rodzaj/kategorię) obiektu. Np.samochód. No i definiuje mu pola. - marka - model - kolor - silnik Potem definiuje telefon - producent - model - simlock Potem definiuje komputer - procesor - RAM - płyta główna Generalnie nie ma prawie (prawie bo niby jest wspólny model ale to przypadek) nic wspólnego między tymi 3 rekordami. W takim razie po zdefiniowaniu tych typów chciałbym wbić parę rekordów do bazy. No i tu jest problem. Czy można wyegenrować różne flexfory dla różnych typów ? Jakiś przykład rozszerzenia które coś takiego ma ? |
|
Napisane: 01.05.2010 [00:44]
|
|
|
dpacholczyk
Twórca tematu
zarejestrowany: 17.09.2008
Posty: 1072
|
chyba znalazłem odpowiedź http://wiki.typo3.org/index.php/Extension_Development,_using_Flexforms#Dynamic_Data_in_Flexforms Wygląda ciekawie  |
|
Napisane: 01.05.2010 [23:08]
|
|
|
kss
admin
zarejestrowany: 19.07.2007
Posty: 829
|
Sprawa nie jest prosta. Jeżeli nawet zadeklarujesz zmienne pola w flexform to będziesz miał potem problem, żeby w prosty sposób tworzyć zapytania, bo flexform zapisany jest w XML. Musiałbyś ładować wszystkie produkty danego typu, przetwarzać XML na tablice (zasobożerne) i dopiero na takich tablicach operować. Nie wiadomo jak skalowalne byłoby takie podejście - myślę, że słabo. No i jak zwykły użytkownik BE będzie mógł definiować nowe felxformy opisujące nowe produkty. Jednym z podejść w takich przypadkach jest EAV http://en.wikipedia.org/wiki/Entity-attribute-value_model Coś takiego stosowane jest w Magento, gdzie zwykły użytkownik może sobie tworzyć dowolne typy produktów z dowolnych pól. Nie jest to proste w implementacji i przy naprawdę dużej liczbie rekordów wydajnościowo też leży - trzeba tworzyć "obejścia". Nie słyszałem o rozszerzeniu w TYPO3, które korzysta z EAV. Innym podejściem jest zaprojektowanie takiego modułu BE w TYPO3, który pozwoli userowi na dodawanie nowych typów rekordów. Będzie to polegało na dodawaniu nowych tabel i nowych pól do bazy, ale oczywiście przezroczyście dla użytkownika. I takie rozszerzenie akurat istnieje i nazywa się "kb_kickstarter". Przetestuj - wydajnościowo będzie z pewnością lepsze niż podejście z flexformem. |
|
Napisane: 02.05.2010 [15:46]
|
|
|
dpacholczyk
Twórca tematu
zarejestrowany: 17.09.2008
Posty: 1072
|
Pierw sprawdzę czy się dobrze wyraziłem. Przez flexform miałem na myśli formularz dodający rekord np. news, a nie wtyczkę np. tt_news Bo możliwe, że źle się wyraziłem. Faktycznie analiza i renderowanei stale rosnące pliku xml w pewnym momencie stałaby się performance killer`em A może jest możliwość aby BE formularz dla danego rekordu generować z różnych plików ? Wtedy rozszerzenie mogłoby generować dla każdego typu rekordu odpowiedni plik i potem tylko je podmieniać. np. tca1.php tca2.php Da się taki myk zrobić ? |
|
Napisane: 02.05.2010 [19:51]
|
|
|
kss
admin
zarejestrowany: 19.07.2007
Posty: 829
|
TCA to nie problem. Można tym sterować np. na poziomie sysfolerów albo poprzez zmianę "type" rekordu. Problemem jest: 1) To jak chcesz to zapisać w bazie - wszystkie cechy rożnych produktów w jednej tabeli? 2) Czy zwykły użytkownik BE ma mieć możliwość dodawania nowych pól? |
|
Napisane: 02.05.2010 [21:15]
|
|
|
dpacholczyk
Twórca tematu
zarejestrowany: 17.09.2008
Posty: 1072
|
Zgadzam się z Tobą, że sposób trzymania tutaj wszystkiego w bazie będzie kluczowy na wydajność. Rozważałem to - na razie bardzo pobieżnie - i doszedłem do pomysłu (moim zdaniem póki co jeszcze słabego) Tabela: Właściwości uid title cat_uid Tabela: Kategoria uid title Na tej zasadzie tworzyłby kategorię, a do kaegorii przypisywałbym właściwości opisujące obiekt. Zapytania byłyby krótkie i stosunkowo wydajne bo wszystko byloby po kluczu szukane Oczywiście zostaje kwestia zapisania obiektu. Obiekt mógłby mieć pole konfiguracyjne typu TEXT które na miałoby postać uid1:value1|uid2:value2|uid3:value3 uidX - to uid pola właściwości valueX - to jego wartość Można to potem wydajnie przeprasować. Co do usera BE będzie miał np. możliwość dodania właściwości a tym samym rekordu. Nie będzie potrzeby rozszerzenia tabel - oczywiście przy założeniu rozwiązania jak powyżej [Ten temat był edytowany 1 razy. Ostatnio 02.05.2010 o 21:16.] |
