Sziasztok!
Van egy excel táblám, amit a Smart Import modullal beimportálom az adatbázisba. Eddig minden rendben, import ok, views megjelenítés ok.
A views-ban ezt az adatbázist felfedett szűrővel szeretném szűrni az egyik oszlop alapján. Ez az oszlop neveket tartalmaz. Egy névhez több sor tartozik. Amikor működni fog, kb 250 különböző név lesz benne, ami lassan növekedni fog. 1-2 év alatt ez a tábla el fogja érni a 15-20 000 sort. Tervezetten 8-10 oszlopot tartalmaz. Az excel táblázat cellái szöveg formátumban vannak.
Az elképzelésem az, hogy a felfedett szűrő autocomplete típusú legyen, hogy a látogató a név begépelésével kerüljön közelebb a keresett névhez.
A segítségeteket szeretném kérni abban, hogy erre a problémára mi a helyes irány.
Milyen mezőtípust használjak / az volt a gondolatom, hogy szótárba kerüljenek be a nevek, de ez importáláskor hogyan működik /?
Előre is köszönöm ha valaki irányba állít.
Zsolt
node-ként jeleníteném meg a
node-ként jeleníteném meg a táblázatod sorait, egy erre a célra készített tartalomtípussal: egy oszlop egy mezőben
(minden bizonnyal szöveges mezők ezek)
- a tartalomfeltöltés importtal megoldható,
- a netezők számára views, felfedett szűrővel
- a későbbi bővítés is megoldható az importálással
...valójában a node a kulcs
Geva
----- Számítások - Kalkulátorok
mezőtípus és......
Köszönöm, ezeken már túl estem.
A sorok egyenként egy node-ba importálódnak és a megjelenítést views végzi.
Igazándiból a kérdésem az, hogy milyen mezőtípusba kellene importálnom azt az oszlopot / Név /, ami alapján a szűrés történne.
Ha sima szöveges mező, akkor a nevet pontosan kell begépelni a szűrő mezőbe. Ezt szeretném elkerülni egy autocomplete mezővel, csak ahhoz a szótárban meg kell jelennie a beimportált neveknek.
Szóval itt kavarodtam meg.
Szerintem ezt nem tudod csak
Szerintem ezt nem tudod csak úgy klikk-klikk megcsinálni. Egyrészt azért importálod (gondolom) textfieldbe, mert ez egy text. Tehát db logika szerint ez így helyes.
Amiről te beszélsz, az már megjelenítési logika, amit semmiképpen nem szabad priorizálni a db logika felé. Ezzel azt akarom mondani, hogy ugyan simán csinálhatnál egy szótárat, és termként elmenteni a nevet, akkor lenne autocomplete-ed filterben, de randa overkill.
Ehhez valami mankót találtam itt: https://www.drupal.org/project/views_autocomplete_api
Az autocomplete használatához meg tök jó példa van: https://www.drupal.org/project/examples
És akár tök jó contrib module lenne: textfield_autocomplete, ami csinál egy field widget, ahonnan a field_foo eddig felvitt értékeiből választhatna az ember, amúgy meg szabad szerkesztésű.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
nevek külön tartalomtípusba?
Lehet, hogy én értem rosszul, de ha egy névhez több sor is tartozik a leendő adatbázisban, akkor nem kellene a neveket (meg esetleg más, hozzájuk kapcsolódó tulajdonságokat) külön tartalomtípusba szervezni? (lásd még: adatbázis-normalizálás) Ez esetben a nevek egy node/entity reference mezővel kapcsolódhatnak, ahol már van autocomplete mező.
SZERK
Reggel írtam egy hosszabb választ, amit vagy elnyelt a moderáció vagy nem. Nincs kedvem még egyszer begépelni, szóval csak röviden. Én importálásra (pl. csv-ből) a Feeds modult használom. Ott meg kell adni soronként egy egyedi azonosítót (GUID-ot), ami független a drupal belső nid-jétől. Ezt lehet használni pl. a versenyző versenyhez (versenyszámhoz stb.) kapcsolásához.
Külön tartalomtípus, de hogyan?
Először én is erre gondoltam, de azután elvetettem, mert…….. kifejtem miért.
Az adatbázis felépítése a következő:
név, születési idő, versenyszám, idő, verseny neve, helyszín, dátum
Egy versenyző több versenyszámban indul egy versenyen.
Minden verseny után ezeket az adatokat leválogatva ( mert csak a saját egyesület versenyzői szerepelnek benne ) kapom meg egy excel táblában. Ez kb 300-600 sor. Ezt a táblát importálom be az adatbázisba. Évente kb 10-15 versenyt kell így feltölteni.
Az elképzelésem az, hogy a szülők/versenyzők számára egy szűrhető nézetet készítek, amiben név alapján le tudják válogatni a gyerekek/saját adatait. Netalán még versenyszámokra is lehetne szűrni, de ez csak egy kósza gondolat.
A jelenlegi fázisban minden szöveg típusban van, kivéve a szül. időt (szám). Ha a szöveg típus szűrőjébe begépelem a nevet működik a dolog. A baj csak az, hogy ha nem helyesen gépelem be, természetesen nem jelenik meg semmi. Ezt szeretném kiküszöbölni azzal, hogy egy autocomplete mező segít az adatbázisban lévő név megtalálásához.
Gondoltam arra, hogy felbontom több tartalomtípusra, de elakadtam ott, hogy az excel táblában hogyan módosítom a több száz nevet node ID-ra manuálisan hiba nélkül.
Minden csak fejlesztés fázisában van, szóval bármi változtatható. Hogyan oldják meg ezt a nagyok? Lehet, hogy a gondolatmenetem nem helyes?
feed importer GUID
Én hasonló importálást a Feeds moduljával végzek csv-ből - de ugyanezt tudja xml-ből is. A smart importert nem ismerem, nem tudom, ott ilyenre van-e lehetőség. A feed-nél meg kell adni egy "külső" egyedi id-t (guid) a node-oknak, ami még véletlenül sem azonos a drupal nid-jével. Ezt a külső egyedi azonosítót a drupal külön kezeli és ezen keresztül mindig frissíthető a node, nem kell ismerni hozzá a belső nid-et.
Tehát én azt csinálnám, hogy van egy excel-munkalap (egyben drupal tartalomtípus) a versenyzőknek, egy másik pedig a versenyeknek (esetleg egy harmadik a helyezésnek). A verseny tartalomtípusban egy node/entity reference mező mutat a versenyzőkre. Beimportálod a versenyzőket, a verseny xls-ében pedig a versenyző guid-ját használod az összekapcsoláshoz.
OFF
Jelezném, hogy az ellenőrző karakteres ellenőrzés (vagy valamelyik másik komponens) kezd meghülyülni, igazából elmenteni sem midig hagyja a hozzászólást. Ezt kb. 4. alkalommal próbálom elküldeni.
jól mondjátok, meg kell tervezni!
kár belemenni a megjelenítés részleteibe, amikor még azt sem tudod mit kell megjelenítened, viszont ha megfelelően megtervezed, akkor azt jelenítesz meg-, szűrsz ki belőle amit csak akarsz, drupallal :-)
...amit fentebb leírsz, az pedig NEM adatbázis, mert pl. mezői biztosan nincsenek az adatbázisnak :-(
1. Válaszd külön az egyedeket(adatbázis tervezés:-): versenyző, verseny, versenyszám,...
2. milyen a kapcsolat az egyedek között
...az egyedekre kell tartalomtípus, amelyben a kapcsolataik a hivatkozások a másik egyedre, ez után vetődhet fel bármi további kérdés
...ha az egészet logikusan és a relációs adatbázis eszméi szerint felépíted(pl egy egyed egy tábla, a forrás adatokat redundancia mentesen viszed fel,...), akkor a drupal megvalósítás is menni fog és a megjelenítés sem lesz gond
Geva
----- Számítások - Kalkulátorok
excel tábla import
Azzal teljesen tisztában vagyok, hogy mit szeretnék megjeleníteni. Az is tiszta, hogy a legtisztább dolog egyedekre bontani és külön tartalomtípust létrehozni az egyedekre.
Ebben a pillanatban van egy tartalomtípusom aminek mezői a fentebb nevezett elemek. (név, szül. idő …..stb). Ebbe a importáltam az adatokat. Szóval szerintem van adatbázis.
Az adatok 1 db excel táblában szerepelnek, amit ha felbontok oszlopaira (egyedekre) és beimportálom a tartalomtípusaikba, akkor nem látom, hogyan találkoznak a sorok újra.
Ha nem importálásról lenne szó, akkor egyértelmű az egyed-tartalomtípus bontás.
Lehet hogy már az excel táblában kéne felbontani valahogy?
Igen
Igen, ezt írtam fentebb, meg abban, amit reggel elnyelt a rendszer.
Haat most lehet, én vagyok a
Haat most lehet, én vagyok a hülye, de eddig amit írtál, nekem úgy tűnik, hogy db szinten teljesen ok vagy. Tehát a megfelelő mezőbe importálsz megfelelő adatokat. (vagy nem?? :O )
Ami az eredeti kérdésedet illeti, nézd meg, amit fentebb írtam.
BTW, simán lehet, hogy félreértem a problémád.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
Szabó Jánosokkal mi lesz? Erre minek node?
"250 különböző név lesz benne"
Ebben biztos vagy? Nem lehet, hogy Lesz több azonos nevű ember?
Ha teljesítmény érdekes, akkor mindenképpen saját modulban gondolkodnék, hisz ez egy sql tábla + egy minimál importer + egy kis megjelenítő modul. Minden más performanciát fog enni.
De ha már kattintgatás, akkor semmi esetre se node és fieldek, hisz a 8 - 10 oszlop az node+field-el 18-22 táblát fog jelenteni az adatbázisban, a lekérdezésekben meg 8-10 joint, amit nem neveznék egészségesnek, főleg, hogy mindegyik field egy mezőt tartalmaz csak és egyáltalán nem lesz szükséged a tonnányi egyéb fontos információra, amit a field modul belepumpál. (ki hozta létre, mikor, milyen nyelven, stb.)
Én az ECK irányában indulnék el... vagyis indultam, mivel nem szeretek úgy javasolni, hogy nem próbáltam ki dolgokat. Össze is raktam egy minta szájtot amit letölthetsz drush archive-ként: http://tanarurkerem.hu/drop/dhu-20951.tar.gz
Létrehoztam egy Entity type-ot, hozzáadtam az excel sorait a Manage properties résznél. Fontos, hogy ne field-ként add hozzá ezeket, mert akkor külön táblába jönnek létre. A legegyszerűbb, ha kikapcsolod a Field UI-t és akkor nem is tudod. :D
A listához a views modul mellett a views_autocomplete_filters modult használtam, és a views_data_exportot, hogy kényelmes felületen tudjam létrehozni az excelt. Te is innen tudsz majd exportálni egyet, ha ki akarod próbálni. Az eredeti terv az volt, hogy a devel generate-el generálok, de az alapból nem tud ilyet, és nem fektettem energiát, hogy keressek ilyen modult.
Az importhoz a Feeds modult használtam és a feeds_eck_processort-t amit egy picit foltozni kellett és utána tök jól működött, kisebb warningokkal, de hát ugye ez egy experimental modul.
Remélem segített ez a kis leírás.
Palócz István
https://palocz.hu | https://tanarurkerem.hu
Szerintem errő lesz szó
Hát azt hiszem valami ilyesmire gondoltam.
Hálám örökké üldözni fog. :)
Ez egy kicsit hosszabb dolog megérteni, ezért egy pár nap múlva jelzek vissza, amikor sikerült átnéznem.
„Ebben biztos vagy? Nem lehet, hogy Lesz több azonos nevű ember?”
A versenyzőket születési idő alapján is megkülönböztetjük. A kb 20 éves tapasztalat azt mutatja, hogy nincs ütközés ebben a viszonylatban.
Köszönöm mégegyszer a problémámra szánt energiádat.
Views Autocomplete Filters
Megszületett a megoldás!
Először is köszönöm mindegyikőtöknek a nyűgömre szánt időt. Különösen köszönöm Istvánnak a tesztoldalt, ennek az áttanulmányozása nyitotta fel a szemem.
Amit az elejétől fogva kerestem, az a views_autocomplete_filters modul.
Az István megoldása nagyon elegánsnak tűnik számomra és borzasztóan tetszik, de ez az entitás dolog még egy kicsit kemény dió nekem. Az agyam még nem fogja fel a nem tartalomtípusba helyezett tartalmak mikéntjét. Tudom, hogy ez is a jövő része, küzdök is vele, hogy megértsem.
Szóval, az adatok egy excel táblában vannak .xlsx formátumban. Azért ebben, mert ebben kapom meg és nem kell konvertálni semmi más formátumba, csak leválogatni. A Smart Import modul, nekem tetszik, mert egyszerű a kezelése és azt teszi, ami nekem kell. Ez a modul .xls és .xlsx formátumokat importál a megadott tartalomtípusba nagyon szimpatikus módon. A tartalomtípust views jeleníti meg, a szűrőjében használom a views_autocomplete_filters-t és az eredmény pontosan az amit szerettem volna.
Kíváncsi leszek amikor nő az adatbázis, hogy hogyan fog viselkedni, de remélem jól.
Köszönöm nektek
Ne várj erre!
Ne várj erre!
Tolj bele annyi adatot amennyi lesz benne. Mivel node-os megoldást választottad, ezért könnyű dolgod van, mert a devel generate-el simán tudsz bele tolni annyi adatot amennyit akarsz. Elsőre ne a maximumot toljad, hanem valamilyen nagyobb lépésekben pl 10, 100, 1000, 10000, tehát valamilyen logaritmikus skálán :)
Lehet az, hogy klikkelgetsz és nézed a feelinget, de lehet azt is, hogy valami tudományosabb módszerrel méred az oldalletöltést.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu