Hejsan,
Jag är en komplett Drupal-newbie och jag tänkte mig använda Drupal för ett projekt.
Jag har därför tuggat mig igenom ett 20-tal screencasts och en massa artiklar. Efter moget övervägande valde jag Drupal 7 över Drupal 6 trots att det är ganska nytt och att så gott som alla screencasts/artiklar jag tittat på beskrivit Drupal 6.
Min målsättning är att slippa PHP-programmering helt. Jag är programmerare med lång erfarenhet av många språk, inklusive PHP, men jag vill kunna bygga denna sajt relativt snabbt, och har inte tid att sätta mig in i API:et just nu.
Det jag vill bygga är en förenings-sajt. Föreningen har ett 15-tal lag, som förutom gemensam information (kalender, nyheter, statisk info mm) alla ska sin egen sida. Denna sida skall administreras av en lagledare, och man skall kunna lägga in nyheter, kalender, laglista, telefonnummer mm mm dvs sånt en lagledare vill kommunicera till sitt lag + föräldrar. Dessutom vill man ha en möjlighet att skicka mail till grupper (spelare, ledare,föräldrar). SMS-funktionalitet är ett plus.
Jag undrar nu hur jag skall begränsa rättigheter till dessa sidor, så att endast ledare kan ändra informationen. Ledare skall dessutom kunna skicka mail, kanske SMS.
Om jag får krångla till kraven, så vill man dessutom låta en lagledare komma åt spelare i andra lag, t.ex. för e-mail, nyheter osv.
Den stora poängen är nu att antalet lag är dynamiskt, rent praktiskt skapas väl knappast lag under säsongen, men varje år blir ju t.ex. U12 (i år födda 1999) ett år äldre och kallas därmed U13. Detta löser man väl med att kalla laget Team99, men varje år tillkommer ju nya lag och de äldsta faller bort. Dessutom är det inte otänkbart att lag bildas och försvinner under säsong (ett B-lag t.ex, eller en temporär träningsgrupp)
Min fråga är, går detta att lösa med OG, och väl funkar det under Dru7? Jag installerade OG men har ärligt talat inte riktigt hittat vägen in än. Blir till att tugga några screencasts till !!
Tacksam för tips!
//Peter
Comments
Som vanligt går det att lösa
Som vanligt går det att lösa på flera sätt. OG har jag inte hunnit använda, men det kan nog fungera.
Min tanke nu var snarare att använda noder och taxonomier. Om jag förstår dig rätt är det bara ledare som ska vara användare och logga in? Isåfall hade jag skapat en taxonomi med lag och spelare som noder. Samma taxonomi skulle då tagga events etc också. sen skapa en ny taxonomiterm för var år. Så kan man lätt tagga en spelare i u13-2010 och i u14-2011 så finns även historiken med. Med views kan man då göra en dynamisk vy med taxonomitermen som argument för att lista den termens spelare. En tränare skulle kunna tagga en spelare med en extra-tagg i taxonomin tex u13-2011-extra eller vad man vill, och då kan mailutskick gå till alla med dessa två termer, utan att störa det andra laget.
Med taxonomierna på det här sättet kan ett event eller nyhet taggas med en eller flera lag, och då kan var lag ha sin kalender och nyhetssida, men träningsledning kan också se en samlad bild med alla lags händelser.
Finns säkert andra sätt, men detta borde då funka iaf.
Jag tror Organic Groups kan
Jag tror Organic Groups kan fungera bra för dig. Du kan enkelt sätta upp grupper med gruppadministratörer som kan e-posta grupp-medlemmarna och bestämma vad som ska visas på gruppens förstasida.
Har använt D6 version i installationer med hundratals grupper och og fungerar bra. Har inte använt eller tittat på D7 versionen för og men hört att den ska ha utvecklats en hel.
Organic Groups, i alla fall för D6, tenderar att tvinga på användarna/grupper ett specifikt arbetssätt/funktioner. Kan man anpassa sig till dessa är og bra, vill man absolut göra saker på sitt eget sätt blir det jobbigt. Mitt tips är att testa och se hur det känns.
Lycka till med Drupal 7! Det är tveklöst den bästa Drupal-versionen men många moduler är inte färdiga ännu så räkna med lite extra strul. Views modulen som du kommer att behöva för og finns t. ex. inte i skarp version ännu. Det är dock bara en fråga om månader innan detta är fixat och allt kommer att handla om Drupal 7.
Jag har nu tänkt igenom vad jag vill ha...
..och tror att följande korta specifikation beskriver detta:
Naturligtvis finns det många andra önskemål, men detta skulle duga som version 1
Jag har inte läst på riktigt om taxonomier (vilket jäkla ord förresten!) eller tags, men det känns lite som det är rätt väg eller? OG visade sig vara svårtuggad för en nybörjare (jag har dessutom en parallell-installation av Drupal6 med OG eftersom alla screencasts/artiklar beskriver denna version och inte mycket ser likadant ut i DR7).
Om jag får gnälla lite så tycker jag inte Drupal är SÅÅÅÅ jädra lätt att komma igång med. Enklare saker visst, men så fort man skall göra något mer avancerat så får man hacka själv. Dessutom har jag definitivt inte grokkat själva tankegången bakom designen av Drupal. Jag tror källan till problemen är att jag har en del förutfattade meningar om hur ramverk normalt funkar, och att Drupal skiljer sig rätt kraftigt åt, kan det stämma? Jag är programmerare och vill gärna se världen i Objekt, och att man skiljer på Modeller, Vyer och Controllers (MVC). Här verkar Noder kunna vara nästan vad som helst, och alla moduler är inne och petar i varandras data. Har jag rätt eller är jag ute och cyklar?
Tack för alla förslag iallafall, jag skall läsa på mer om Tags och Taxonomier (Jag bara önskar att jag inte behövde läsa så mycket...)
PS: Det största problemet jag har är att jag skall ersätta en gammal sajt (ASP) som byggts på i snart 10 år. Hopplöst omodern men den funkar och ingen vill tappa nån funktionalitet som finns där..... DS
Drupal är komplext, svårt att
Drupal är komplext, svårt att undvika när man vill ha ett flexibelt och kraftfullt system. Så det finns definitivt en inlärningskurva.
Vill man bygga lite mer komplexa system, som ditt exempel, är det första steget att veta vilka moduler man ska plocka samman och hur bästa ska konfigureras.
Du kan troligen bygga din webb-plats till 95 procent eller mer helt utan egen kodning. De sista detaljerna hoppar man över eller så bygger man en custom modul för dem.
Du behöver sätta dig in i och omfamna Drupals grundläggande arbetssätt så du inte motarbetar verktyget.
Då du är programmerare kan denna artikelserie kanske vara av intresse, http://becircle.com/drupal_7_line_by_line_part_1_introduction.
Att försöka kopiera varenda liten funktion och egenhet från en gammal webb-plats till en ny leder i min erfarenhet till mycket bortslösad tid och frustration.
Mycket bättre är att börja med ett blankt papper. Vilka funktioner är det vi verkligen behöver i vår dagliga verksamhet? Hur kan Drupals styrkor användas för att få till dessa funktioner så enkelt som möjligt?
Hej igen och tack för
Hej igen och tack för svaret!
Jag har redan börjat läsa artikelserien, den verkar intressant, men den förutsätter som sagt att jag vill fördjupa mig i de innersta detaljerna av Drupal. Nu kan jag väl tänka mig att göra det, men för principens skull så vill jag gärna veta vad en icke-programmerare skulle göra.
Skulle du säga att mitt exempel är komplext? Jag tycker iofs inte det, men hur skulle en 95% lösning se ut då? Vilka delar är det som Drupal inte klarar av i utgångskonfigurationen?
Jag tänker inte helt kopiera den gamla sajten, det är inte avsikten. Men ovanstående funktioner behövs för att verksamheten skall fungera. Vi har naturligtvis en massa önskemål om förbättringar, och då måste alternativet "bygga nytt" vara konkurrenskraftigt med "lappa det gamla systemet".
(Så att vi inte hamnar i "Second System Syndrome" som du säkert känner till - jag har varit där ett par gånger).
Jag tror jag hamnar vid en kärnfråga: vad är egentligen Drupals styrkor?
Artikelserien länkade jag
Artikelserien länkade jag till då du är programmerare och kanske tycker det är intressant att veta vad som händer i bakgrunden.
Siffran 95% var baserat på min erfarenhet av att bygga webb-platser med Drupal efter kunders önskningar. Inte specifik för ditt fall, borde varit mer tydlig med det.
Drupal styrkor skulle jag säga är att systemet kan byggas ut med en lång rad högkvalitativa moduler. Dessa moduler är inte färdiga/statiska lösningar utan istället byggklossar som kan kombineras efter aktuella behov.
I de fall man inte hittar en module som täcker ens behov finns ett utmärkt API och dokumentation för att bygga egna.
I ditt fall skulle jag testa att bygga webb-platsen med i första hand og och views. Modulen rules är bra att ha i sin verktygslåda också, man kan lösa mycket saker med den. I Drupal 6 använde og modulerna messaging + notifications för att möjliggöra användarnas prenumerationer av nytt innehåll, gissar att det är så i 7:an också.
(Själv använder jag också alltid context, strongarm och features för att få mer kontroll över blockplacering samt få så mycket inställningar som möjligt som kod så den kan versionhanteras etc.)
I princip alla moduler du behöver är i dev, alpha eller möjligen beta versioner. Räkna med lite extra strul under några månader tills allt kommit på plats.
Lästips: The Drupal Learning Curve: a configurators view
En pragmatisk väg framåt
OK tack för infon.
Jag har nu tänkt till, och reducerat ner funktionaliteten. Kan du svara på om detta är möjligt:
Jag spolar OG och satsar på Taxonomies.
Varje medlem (förälder, spelare, ledare) måste existera som en user i systemet (registreras i förväg av oss)
Man behöver inte logga in för att titta på information
Alla kan titta på alla andras lag-information
Jag taggar varje user med LAG (TeamA, Team99, Team03 osv - man kan ingå i flera lag) samt TYP (Spelare, Ledare,Förälder) (KAN man föresten tagga users??)
Jag taggar nyhet med INTRESSENT (Alla, TeamA, Team99 etc etc) samt NYHETSOMRÅDE (Styrelse, Sport, Kansli, Info etc etc)
Lägger upp en vy (Views?) för varje lag, tex Team99:
Visar alla users med tag Team99.
Visar alla nyheter med tag Team99 eller Alla
Jag vill sen kunna sätta upp att en user taggad Team99 skall få ett e-mail om man lägger in en nyhet med tag Team99.
Samma funktionalitet fast SMS.
Alla ledare kan lägga upp nyheter och tagga dem ( inormalfallet taggar man sitt eget lag men inget hindrar en från att lägga in en nyhet och tagga andra lag i den)
Kommer jag hit har jag en stor del av funktionaliteten, och har antagligen begripit lite mera av Drupal också!
Vilka moduler behöver jag till ovanstående? Är det rätt tänkt? Jag tror att om jag genomför denna del, kommer jag begripa en hel del annat på vägen, bara jag blir styrd in på rätt tankesätt..
Tack på förhand!
//Peter
Jag har nu lyckats skapa Taxonomy Tags på Story-noder..
..och kan dessutom skapa både Block och Page-Views som väljer ut dessa baserat på Tags. En fantastisk framgång eftersom jag ett tag var ganska bortkollrad. Lätt är Drupal inte!
Men jag har nu fastnat på hur jag skall tagga users med mina Taxonomies (LAG i första hand, men även TYP). Finns det nån sån modul för att lista Users i en view, eller har jag missat nåt?
Sen tänkte jag skapa en Block View av utvalda users, och låta min lagsida bestå av ett User-block och ett Story-block.
Till att börja med...
Du skapar då din vy baserad
Du skapar då din vy baserad på användare, inte noder, på förstasidan när du skapar din vy.
Ja jag har lyckats göra en vy på användare, men hur taggar jag..
..en user med Team99? Jag kan ju bara filtrera på exvis User:Roles,User:Name osv? Många är ju ledare (roll), men bara ett par är ledare i Team99 (taggade med Team99)?
Jag testade nu och du får
Jag testade nu och du får filtrera på field_term (jag kallade mitt taxonomifält på user för term) eftersom taxonomin räknas som ett extra-fält i det här fallet. För du har väl lagt till ett taxonomifält på användarkontona?
Nix, det är precis det..
...som jag letat efter?! Var sätter man det, har kollat överallt !!
EDIT: Hittade efter mycket letande modulen user_terms
har inte du Drupal 7? den
har inte du Drupal 7? den modulen stöder bara D6 som jag kan se. Jag fick det att fungera utan problem och extra moduler i D7.
om du går till /admin/config/people/accounts/fields på din site kan du där lägga till fält på användarkontona, och sedan bara filtrera på dem i views som vilket fält som helst
Nä jag gick tillbaka till Dr6 eftersom..
...alla screencasts och artiklar beskrev version 6 och allt i verison 7 såg så annorlunda ut. Det är tillräckligt svårt att lära sig ett nytt verktyg! När jag fattar sammanhanget i Dr6 kan jag sen köra vidare i Dr7. Som nybörjare tycker jag att det svåraste är:
1) Att hitta rätt arbetssätt (dvs Jag vet hur man gör detta "normalt", men hur tänker man i Drupal??)
2) Att hitta en modul som gör det man vill
3) Hitta dokumentation/screencast för detta!
När man väl har fattat vad man skall leta efter går det lättare, men jag tycker fortfarande det är hemskt svårt att vet VAD jag letar efter när jag vill göra en speciell grej. Det är också svårt att bedöma kvaliteten på alla moduler som finns därute.
Det är inte alls lätt. man
Det är inte alls lätt. man får kolla lite på sådana här saker har jag lärt mig av Itangalo:
(det är inte nått citat, men det är såhär jag kommer ihåg det han pratade om på en demo)
Jag har under förra sommaren skapat en site i D6, nu var det dags för en annan site, min andra drupalsite, och jag väljer D7, och det hade jag nog faktiskt gjort i dina skor med, även om nästan alla screencasts och annat är på D6, detta för att det är här utvecklingen ligger för många, många moduler kommer sakta men säkert att fasas över till D7 helt, och kanske sluta supportas på D6. D7 ligger visserligen i sin vagga nu, och många moduler är inte riktigt klara än, det tar enligt någon annan här på g.d.o/sweden gissade ett halvår eller så innan det viktigaste är helt på sin plats. Det känns tryggare i min värld att vara med i det nya, än att halka efter och behöva lägga ner massor med tid på en uppgradering när buggar slutar fixas på D6-moduler.
Det är ungefär som att börja köra Vista i stället för XP när Win 7 släppts...
Jag köper argumentationen..
..och slutligen blir det antagligen D7, men det kostar ju väldigt lite att ha multipla installationer, så just nu har jag flera D6 och en D7 installation.
Så jag lär mig på D6 eftersom screencasten finns där. Det är inte tekniken i sak jag har problem med att förstå, utan själva "tänket". Jag har märkvärdigt svårt att begripa hur Drupal är uppbyggt. Jag hade hoppats slippa djupdyka, men det verkar nästan som jag måste bygga en modul själv för att förstå hur allt hänger ihop.
PS. Jag kör till 95% Ubuntu och Mac, efter 25+ år med DOS/Windows. Endast när jag är nödd och tvungen sätter jag mig vid Windows-burken. Kör tom Ubuntu på alla mina laptops. DS
jag tycker att det inte är
jag tycker att det inte är allt för stor skillnad på tänket i D6 & D7, gäller bara att hitta lite i den omstrukturerade administrationsmenyn samt att många moduler som man normalt alltid ändå installerade på D6 nu finns med i core på D7.
För mig personligen kom genombrottet på en halvdags genomgång av Itangalo på Drupaldagen i Karlstad i maj 2010, innan dess hade jag inte ens installerat en drupal, efter det byggde jag en utan jätteproblem. Jag kan tänka mig att de flesta programmerare gör felet att tänka på drupal som något som ska byggas klart som om det vore ett framework. Jag kom snarare att tänka på drupal som ett affärssystem som måste anpassas konfigurationsmässigt till verksamheten och då föll allt på plats i huvudet mycket smidigt - jag har inte djupdykt nått. det enda programmatiska jag har gjort är att skapat ett eget subtema som drupal kallar det och anpassat page.tpl.php och style.css för att passa layouten.
Jag har hållit på länge med både det ena och det andra, men jag har varit aldeles för lat för att orka köra linuxen på heltid, så jag stannar i windows, även om jag vet vad det handlar om utan problem. Windows var ju givetvis bara en liknelse, men det tror jag nog att du förstod :-)
För övrigt tycker jag att det låter som ett spännande projekt du har företagit dig, och följer det gärna närmare, både som påhejare och komma med konstiga förslag och ideér ibland :-)
Det är bra att kunna bolla ideer..
..och kunna ställa lite dumma frågor, så tack för att du svarar på mina helt klart förvirrade antagande!
Jag skulle förresten vilja ha en löpande diskussion om mina duster med Drupal och en förenings-sajt, är detta forum rätt ställe för detta? Känns som att tråden skulle kunna bli väldigt lång! Finns det nåt bätrte ställe så tipsa mig gärna.
Iallafall, när jag pratar om "tänket" bakom Drupal, så menar jag den bakomliggande designen. Jag har tuggat lite kod och API idag, och har fått för mig följande:
Drupal byggdes från början för att hantera artiklar (nyheter eller bloggposter osv) samt kommentarer på detta. Detta är Drupals hemmaplan, allt detta är skitenkelt. Eftersom det var så enkelt att bygga en sajt började sedan man lägga till funktionalitet för att klara det som Drupal inte var skapat för till en början. Man har byggt på och refaktoriserat allt eftersom, på ett fundament som egentligen var tänkt för nåt helt annat. Man har byggt ut ett generellt/flexibelt Nod-koncept till att hantera helt makalöst mycket! En del helt geniala saker har byggts på något som jag kan tycka är en rätt ranglig grund.
Men nu till mitt grundproblem.
Jag började lägga upp ledare som users, klickade på "Team97" resp "Materialare" (Taxonomy-terms som jag lagt till) eller vad det nu var som de gjorde. Kom på efterhand att jag glömt en massa fält, t.ex. telefonnummer och e-mail. Nu är det ju så att en del har ett nummer, medans andra har 3-4 telefoner. Än värre med e-mail naturligtvis.
Sen upptäcker man rätt snart att en user som är ledare i ett lag, kanske bara är förälder i ett annat. Jag har inte ens nämnt relationer förälder-barn (begreppet familj t.ex - viktigt när man skall betala medlemsavgift med familjerabatter!) Då kommer frågan hur jag löser detta.
I ett traditionellt system, lägger man upp tabeller i en relationsdatabas, Ett-till-många eller många-till-många relationer. Nuförtiden plain vanilla att lösa detta.
Nu har jag förstått (? tror jag ?) att Drupal inte använder databasens relationer, utan lägger upp "mjuka" relationer i sina tabeller. Jag förstår precis tanken bakom detta (flexibilitet) men samtidigt får man ingen hjälp av databasen i prestandahänseende. Dessutom oerhört viktigt att inte nån modul förstör nån relation. Med SQL kan man ju ha hårda regler som förhindrar data-korruption, men i Drual verkar det enkelt att röra till det i databasen med en dåligt skriven modul.
Dessutom har jag förstått att Drupal är väldigt databas-intensivt, och med tanke på ovanstående kan jag nästan förstå detta. Jag upplever Drupal7 som ganska segt, men har hittills gissat att jag inte konfigurerat rätt. Jag har inga större problem emd det just nu, men vad händer när man har hundratals användare?
Flexibilitet med variabelt antal fält kontra prestanda med mindre flexibilitet är ju ett klassiskt problem. Jag velar fortfarande mellan vad jag föredrar, det är naturligtvis olika i olika situationer. Flexibiliteten borde leda till en mängd databas-accesser, och lite sämre prestanda eftersom man mister databasens optimering av frågor.
I mitt fall, så skall jag ju (om jag nu går hela vägen) försöka implementera en kopplingstabell, där jag kan lägga upp 1..n telefonnummer, samt 1..n e-mail-adresser per user. Det känns lite som att jag får böka in denna information med ett bräckjärn för tillfället!! Att lägga till enskilda fält på en user kan jag väl stå ut med, men hur jag ska kunna ha variabelt antal telefonnummer (t.ex) vet jag inte alls just nu.
Så frågan är om Drupal verkligen är rätt verktyg i detta fall. Ser man på formulärhantering och databaskod är t.ex. Ruby on Rails betydligt enklare (plus att man får riktiga databasrelationer på köpet). Dock förlorar man flexibiliteten att lägga till fält i runtime mm. RoR är klassisk programmering, med alla dess fel och brister, men med rätt design blir det ganska bra och kanonprestanda. Dessutom äkta MVC. Men det tar ganska lång tid att koda, och det ville jag undvika i detta fall.
Jag kommer nu ändå att köra detta spår i botten med Drupal, men jag ville förklara lite vad jag menar med "tänket" bakom. Om jag får flexibilitet och kort utvecklingstid kan jag köra Drupal, men skall jag hålla på i flera månader för en sån här lösning, då kör jag hellre RoR eller Java och gör det "rätt" (hoppas jag inte förolämpar för många nu!).
Jag har dock inte gett upp ännu! En något reducerad lösning verkar vara framkomlig, men det känns ju lite synd att inte kunna göra det som man vill.
Okej, taxonomierna är mer
Okej, taxonomierna är mer avancerade än det ser ut. De är nämligen inte bara en lista termer, utan också ett helt termträd! Du kan gå in på en taxonomiterm och förklara den som child till en annan term, så du kan göra termerna team99-förälder, team99-ledare, team99-spelare till undertermer till team99. Än roligare blir det, för en term kan ha obegränsat med föräldrar också, så din team99-ledare kan ha en parent-term ledare förutom parenttermen team99
Problemet med multipla fält är redan löst. Du kan för var fält ange om det tar ett eller flera värden, eller tillomed obegränsat, på så sätt kan man lägga till fler telefonnummer allt efterhand, utan att krångla, och dessa extra flervärden lägges till från edit-sidan, inte bygg-sidan. Drupal gör nämligen en tabell för var fält som relaterar till noden eller användaren i det här fallet. Informationen lagras vertikalt istället för horisontellt, vilket medför andra fördelar, som just en lös koppling, som i det här fallet är utmärkt.
Ja det är databasintensivt, men det fungerar oftast utan märkbarhet enligt min lilla erfarenhet.
Men växer det för mycket kan databasen behöva skruvas på i inställningarna. Nästa steg som minskar databasaccesserna är det som jag förstår välutbyggda cache-systemet i Drupal. Det är ju oftast många lika visningar innan sidan ändras. Denna cache vet jag jättelite om dock, men det kan nog nån guru som jobbar med drupal dagligen svara på.
En fördel med lösa relationer är också valfriheten på databasmotor, då det knappt behöver tänkas på om det är en sqlite eller en klustrad oracle det ligger på. Ja en dåligt skriven modul kan sabba allt, men så är det ju i alla system.
Hoppas detta ger dig nått! Hittar du inte, eller undrar mer/förstår inte, fortsätt fråga!
Familjer skulle jag nog lösa som innehållstyp med user reference fält...
NU börjar det likna nåt!
Bra information, tack! Jag är väldigt tacksam för att jag får tjata med nybörjarfrågor såhär.
Att jag missade antal värden på ett fält var obegripligt, eftersom jag hittade det direkt för taxonomier!
Hierarkierna med termer var värre. Jag fattar inte riktigt vad hierarkin består i? Som jag fattar det kan man bara ha en hierarki inom ett vokabulär? Kan jag inte ha en hierarki LAG-TYP, dvs Lag={Team00,Team99,Team98,Team97} och TYP={Ledare, Förälder, Spelare} ?
Som jag fattar det går det inte att göra så. Man måste ju kunna söka ut "förälder" {* - "Förälder"}, oavsett lag, och alla i ett lag, oavsett funktion {Team99 - *}.
Vissa ledare har nu kanske Team99 och Team96 ikryssat, samt "förälder" och "lagledare". Ingenstans kan man dock se i vilket lag han är ledare... eller om han är Förälder i båda eller bara ett lag.
Nån ide här?
Hur gör du förresten om man vill testa sökningar på termer, finns det motsvarigheten till en sql-terminal, eller skall man göra en view för att testa utsökningarna?
Om du redigerar en
Om du redigerar en texonomiterm så kan du längst ner hitta en i förhand dold inställningskategori "Relationer", klicka på namnet så kan du välja lite mer där, då väljer du att en term ska vara parent till en annan. skapa då bara en term "lag" så kan du sätta alla lag som barn till den termen.
det är nog lättast med en view skulle jag tro. finns visserligen lite andra moduler som jobbar med taxonomier, men vet ingen på rak hand som passar för det.
Ja jag har sett den, men fattar inte riktigt....
Jag har gjort som du sa (har sett den där Relationer fliken faktiskt), och lagt in termen Lag i vokabuläret LAG. Förut hade jag termerna Team95...Team02, alla dessa har jag nu gett parent "Lag'.
Jag har också vokabuläret TYP, med termer Ledare, Spelare, Förälder. Skall jag alltså skapa dessa termer i vokabuläret LAG istället? Och skapa en ny term "Typ" som blir parent till dessa tre?
Skall jag ha flera term-fält i usern, där varje fält är en roll? Alltså att en user har en rad där Lag-Team96 är vald, och en rad där Typ-Ledare är vald? Hur säger jag sen isåfall att han även är en Team99-Förälder.
Eller skall jag ha ett hierarkiskt vokabulär med termer Team99-Ledare, Team99-Spelare, Team99-Förälder, sen Team98-Ledare osv?
Nä nu känns det som jag gått vilse, har du nån ledtråd?
Jag skulle nog samla allt i
Jag skulle nog samla allt i en och samma taxonomi "roller".
i denna skulle jag då skapa en Lag-term, under den skulle alla lagens termer ligga
sedan under denna term skulle jag lägga alla kategorier som tillhör det laget
hm. intressant träd det blev med detta ul-träd jag gjorde... lite felvänt liksom.. nåja, jag tror du förstår.
Detta ger dig nämligen funktionen att om du söker efter användare med termen förälder, får du alla underliggande också, om jag inte minns fel.
Sedan kopplar du bara alla nödvändiga termer till var användare...
Det är ett extremt arbete att ordna detta, men jag tror det blir bra i slutänden.
Jag *tror* jag förstår...
men det känns inte bra.... Du menar alltså att jag skall skapa produkten av alla typer och lag??
Om jag sen då lägger till ytterligare ett nivåer, t.ex Ledare kan vara Tränare,Materialare,Massör,Lagledare och Tränare i sin tur "Huvudtränare" resp "Assisterande tränare". Ändå vill man referera till dem som "ledare" respektive "tränare". Då växer det till en ohanterlig storlek, korrekt?
Så stort som produkten av
Så stort som produkten av borde det inte behöva bli, men stort blir det. Frågan hur du annars gör det smidigast. Du vill ju ha en specifik roll per lag, och då ser jag inte hur man annars kan få den kopplingen, just eftersom personer kan ha flera roller och du vill kunna se i vilket lag man har den rollen.
Vänta lite. Du skulle kunna skapa lag som en innehållstyp med ett user reference field för var roll i laget och ha dessa i flervärdesform. Frågan är väl bara hur man då bäst får det enklast sökbart...
Jag förstår problemet och komplexiteten, men det är svårt att välja väg dit. Skulle vara kul om nån annan av sweden-gruppens medlemmar kunde ge sin syn på detta!
Jag vill inte överarbeta detta ämne....
..men principellt skulle jag vilja veta hur man gör. Annars finns det nog sätt att komma runt problemet, för det rör som du säger egentligen bara två nivåer, men din lösning känns inte så elegant, mera "brute force".
Kanske man reder ut problemet om man ställer upp alla krav så här:
En user kan ha flera roller (lagledare + förälder i Team99 + förälder i Team96 + cafeansvarig i Team02)
En user kan ha flera andra egenskaper (kansliet, styrelsemedlem, cafeansvarig-förening, kan slipa skridskor, har buss!)
Man vill kunna plocka ut (t.ex för SMS, Mail, Nyhet)
alla Spelare i Team99
alla Ledare i alla lag
alla Materialare i alla lag
Alla styrelsemedlemmar
osv osv
Allt utom Roll + Lag är "enkla" egenskaper som är lätta att hantera.
I en databas skulle jag ha en Role-tabell, men titel på rollen samt id-pekare till Lag-tabellen och User-tabellen, och så var problemet löst! Nog borde det väl gå att göra en liknande simpel lösning i drupal??
Är det det du syftar på med en innehållstyp?
Har du förresten tänkt något
Har du förresten tänkt något på innehållstyper? Story kan ju lätt användas till nyheter, där passar den bra, page till statiska sidor passar också bra, men du behöver troligen skapa fler.
Event; med ett datumfält -> använd modulen date, för att visa i kalender, modulen Calendar
Några andra bra moduler:
ctools (har du troligen redan om du har views)
ckk (för att kunna lägga till andra typer av fält)
link (för att kunna lägga till fälttypen länk)
locale updater (laddar ner språkuppdateringar, perfekt nu när översättningen uppdateras ofta)
pathauto (hjälper till att skapa bättre urls, bättre SEO etc)
Jo jag har tänkt mig egna innehållstyper...
..men jag tänkte bara lösa de grundläggande problemen först!
Alla de du nämner finns nog med på min kortlista över bra moduler.
Hur har det gått för dig? Har
Hur har det gått för dig? Har du kommit något längre? Hur känns det och vad är problemen nu?