Hvordan renske drupal sin (x)html output?

[espenhogbakk]

Hei,

Jeg har for andre gang havnet i et Drupal prosjekt, det er mitt andre, men mitt første med D6. Jeg er ikke spesielt fan av Drupal (mer en Django fan), men trur mye av min misnøye er fordi jeg syntes det er vanskelig å skjønne hvordan jeg kan ha kontroll på hvilken html output Drupal genererer. I mitt første prosjekt må jeg innrømme at jeg ikke gadd å bruke tid på det, og brukte det som Drupal spyttet ut ukritisk.

Men nå har jeg lyst til å få brukt Drupal til å generere semantisk markup... Men det ser umulig ut. Jeg har ut i fra anbefalinger begynt å subtheme Zen. Og jeg har fått rensket opp endel ting jeg vil fra basis themet, blant annet utelukket en haug av css filer osv som den bruker. Men det jeg ser som det største problemet er Views sin markup. Views modulen i seg selv er jo ganske genial, og jeg syntes det er rart den ikke er med i Core, men hvis man bruker views så får man uren markup. Så tittet jeg på kildekoden til mac1.no som kjører på Drupal og jeg ser at her har de klart å få pen markup.

Så jeg er interresert i å få noen tips på hvordan man kan renske opp markupen og få muligheten til f.eks å definere egne klasser og id'er på tagger f.eks. Bruker dere views her på i1 nettverket? Og hvis ikke, hva er fremgangsmåten uten views?

Sånn views er nå så wrapper den jo alt av lister osv inn i 3-4 nestede divs og det er jo kjekt hvis man skal ha muligheten til å gjøre alt av styling med css, men det er jo ikke veldig semantisk.

Finner også veldig lite dokumentasjon/diskusjon rundt dette i Drupal communitiet, så hadde satt veldig pris på noen pekere.

[ak]

Hei,

for øyeblikket bruker vi hverken Views eller CCK på i1 sidene, men vi har brukt det i en del biprosjekter og litt kommer nok her også. Jeg husker ikke om Views går inn i Drupal 7, men CCK gjør ihvertfall det.

Alternativet til Views og CCK er å lage egne node typer rett i en modul (kode). Det ligger i sakens natur at CCK og views må bruke ganske mye wrapper markup for å være fleksibel.

Når jeg skal ha en node type til å se ut akkurat som jeg trenger så lager jeg som regel node-<type>.tpl.php filer , og plukker $node objektet fra hverandre inni der og legge ønsket markup rundt.

Hvordan du best gjør dette med Views vet jeg ikke, men det finnes en API som lar deg først lage View objektet, eventuelt endre det, og så rendre det.

Til slutt har du denne, men den er ganske vanskelig å bruke: http://api.drupal.org/api/function/hook_nodeapi

[espenhogbakk]

Aha, det forklarer litt. Ja det med å style selve noden i tpl fil er jo greit nok, det har jeg begynt med, eventuelt via content templates selv om jeg ikke er noe fan av det.

Det jeg kunne ønsket meg var noe ala views hvor man kunne lage sql spørringene og hente ut data på den måten views gjør, men at man kunne fomatert outputen slik man selv ville. F.eks ved at du har har alle variablene tilgjengelig i en tpl fil og at man med noen variabler osv kunne definert det helt selv.

Hvis man ikke bruker views, slik dere gjør, hvor legger dere sql spørringene, og hvordan løser dere pagination f.eks? Og finnes det noen ressurser på slik utvikling på nettet? Finner stort sett bare ting rundt views...

[ak]

Årsaken til at jeg bruker Views i det hele tatt er at det tar tid å gjenskape tilstrekkelig markup, og velge felter fra objektene. Så hvis du skal gjøre den biten fra scratch så kan jeg ikke komme på gode grunner til å bruke Views, å plukke ut noder via SQL er ganske lett som du sier.

Minimal modul:
1) hook_menu for å registrere sti for callback
2) callback funksjon som rendrer siden
3) Bruk et argument x som sier start hvor den starter, /dinmodul/dinside/x
3) I SQL spørringen til db_query(), bruk ORDER BY <felt> LIMIT <x>, <x+10> for å vise ti av gangen per side

Contemplate var greit nok, men siden det (ihvertfall i D5) alltid tar utgangspunkt i standard visning av alle felter (i CCK har du egentlig mulighet for å justere hvordan de vises, om label skal være med osv.) så skjønte jeg egentlig ikke poenget med å bruke dette fremfor node-type.tpl.php.