Basetheme konklusion
# Base theme til Ding 2
Før udviklingen af base theme til Ding 2 har vi testet og evalueret på adskillige fremgangsmåder. Dette for at sikre at Ding2tal projektet ender ud med det bedste og mest fleksible Drupal tema.
## Konklusion Vi har konkluderet at basis temaet til Ding 2 bygges fra grunden uden brug af andet base theme. Vi har vurderet at dette giver det absolut mest fleksible og det bedste resultat. Vi ender i så fald ud med nøjagtig hvad vi ønsker, hverken for meget eller for lidt.
## Hvorfor ikke bruge et base theme Vi har evalueret på om vi skulle benytte et af følgende temaer som base theme til ding2tal base themet. Men konkluderet at ingen vil tilføje noget ekstra, de vil snarer alle tilføje for meget som ikke skal bruges. Temaer vi har gennemgået:
* Omega
* Adaptive Theme
* Zen (version 5)
* Framework
* Skeleton
Der er ingen tvivl om at de alle har deres styrker og er rigtig gode base themes. Men Ding 2 er så specifik og ønsket om et meget fleksibelt dedikeret base theme til Ding 2 gjorde frasorteringen nem. Vi vil simpelthen skulle tilpasse for meget ved at bruge et base theme til vores base theme.
## Latto Det nye base theme til Ding 2 hedder derfor Latto og bygges fra grunden ved brug af følgende principper.
### Cherry picks Der er ingen tvivl om at mange andre base themes til Drupal indeholder elementer som vi kan drage nytte. Så fremfor at basere os på et enkelt vil vi pille ting ud fra flere og implementere hele eller dele af disse i Latto.
### Test Driven Development Vi arbejder med et princip vi kalder Human Test Driven Development. Vi skriver alt markup og css på forhånd så det er testet af mennesker før det implementeres i temaet og/eller ding 2 moduler. Til dette formål benytter vi https://github.com/jakobloekke/tdcss.js.
### SASS og Compass Vi udnytter de fantastiske egenskaber som SASS og Compass giver i forhold til at skrive enkel og browser venlig css.
### Zen-Grids Vi har valgt at basere vores grid system på Zen-Grids som er en compass extension og derfor nemt implementeres i koden. Zen-grids er envidere responsivt, skrevet af en Drupal udvikler og benyttes i seneste version af zen. Dette øger på sigt antallet af Drupal sites som benytter grid systemet og dermed adgangen til viden.
### Simplicity Et vigtigt element er at holde tingen simple og skrive kode som kan genbruges. Vi ønsker ikke at Latto skal indeholde overflødelige elementer. --- Koden til Latto kan findes her: https://github.com/ding2tal/latto
Snittet mellem Latto og subtemaet DDBasic er beskrevet her
Kommentarer
En fin lille gennemgang - god
En fin lille gennemgang - god baggrundsinfo for nye udviklere til ding2tal.
CSS preprocessor: hvorfor?
Hvordan er I kommet frem til at bruge en Ruby baseret CSS preprocessor?
Og hvilke fordele ser I, iøvrigt ved at anvende en CSS preprocessor for ding2tal-projektet?
SASS tilladt jf. Ding code guidelines
Ud over argumenterne fra zorp og martinb14, så tillader Ding code guideslines brug af SASS.
Bemærk at det ifølge code guidelines er udviklernes ansvar at kompilere filerne således at der ikke er en afhængighed til Ruby i produktionsmiljøet.
Da disse blev publiceret var der en længere debat vedr. Ruby, dependency chains etc., hvor jeg selv advokerede for en PHP baseret løsning. I sidste ende blev det ikke sådan, og baseret på martinb14s erfaringer med sassy etc., ser det ud til at vi traf det rigtige valg.
Fin opdeling
Jeg havde ikke set SASS tråden i guidelines, men det giver rigtig fin mening at adskille produktion og udvikling på den måde.
Imellemtiden håber jeg på at SASSY på et tidspunkt bliver standard komplet.
Ang. workload så cacher prepro fint den kompilerede css og fungerer med Drupals egen aggregat cache.
Ok, og ikke LESS?
Ok, og ikke LESS?
Ikke LESS
Nej - vi ville gerne holde os til ét system.
Vores indtryk, da code guidelines blev udformet, var at Drupal miljøet hældte imod SASS. Det ser også ud til at SASS har større udbredelse i contrib themes.
Ruby og Sass
Der er mange gode argumenter for css preprocessing, men det er ikke så sjovt at skulle være afhængig også af Ruby.
Vi har forsøgt at komme uden om Ruby compileren bla. med Sassy men det lader ikke til at PHPSASS er modent nok endnu. Den har graverende fejl og understøtter ikke den komplette originale syntaks.
Jeg håber på sigt vi kan komme uden om Ruby, men for nu er vores løsning på fkb følgende:
-prepro som preprocessor proxy
-Nyt sassruby modul til prepro så ruby gem'en sass kompiler scss og sass filer.
-Patch til prepro så der kun kompiles scss/sass ved ændrede filer.
Jeg lægger sassruby og patch på github til interesserede.
Der er ingen tvivl om, at der
Der er ingen tvivl om, at der er mange nyttige features, der kan drages nytte af med disse værktøjer. Men værktøjer skal vælges, baseret på projekt og arbejdsgang. I mange tilfælde ville det være en fantastisk måde at skabe stylesheets med disse værktøjer. Men for ding2tal?
Jeg tænker på, om der har været overvejelser (vurdering af gevinst, forbedring af arbejdsproces, etc.), omkring det voldomme overhead som det giver? Vil det spare så meget tid, at det opvejer ulemperne?
Preprocessor
Jeg er helt enig i at Ruby er et ikke kærkomment overhead man lige skal overveje.
Omvendt, hvis PHPSASS var modent, ville jeg ikke tøve med at installere prepro og sassy som default i drupal, og dermed få et godt css værktøj uden yderligere dependencies.
Der compiles ikke runtime.
Der compiles ikke runtime.
Runtime
Prepro compiler on the fly hvis der er ændringer i filer og caching er slået fra (og det er vel runtime?), -modsat andre lokale udviklingsværktøjer som varetager kompilering til css særskilt fra afvikling af php.
Det er klart at i produktion er alt dette underordnet da der hverken er ændringer i filer, og at css er hårdt cachet.
Jeg er blot interesseret i hvorledes man kan etablere et så effektivt udviklingsmiljø som muligt. Og det er selvfølgelig smag og behag om man vil have et tredieparts program til at watche sine udvalgte scss foldere eller om man foretrækker dem kompileret i samme omgang som php.
For udviklingsarbejdet med
For udviklingsarbejdet med base themet er SASS og Compass i overordentlig høj grad et tidsbesparende værktøj.
Der er intet krav om at et sub-theme som du/i laver senere hen benytter SASS det er udelukkende selve base themet og i udviklingen af dette vi benytter SASS/compass. Det gør rigtig rigtig mange ting meget enklere i udviklingsprocessen. SASS og Compass sparer os tid og penge.
Vi compiler css filer med Codekit og har intet besvær eller overhead overhovedet. Tværtimod har vi stor glæde af includes, mixins og extend.
Jeg tænker ikke så meget
Jeg tænker ikke så meget overhead ift. Ruby, og jeg er orienteret om at det kun drejer sig om base themet.
Af overheads kan der nævnes:
Overhead
Nu er jeg ikke selv inde over valget vedr. brug af SASS i Ding2tal, men jeg ser ikke de nævnte overheads som problematiske.
Jeg tror personligt ikke at brug af SASS i Latto vil gøre denne opgave mere eller mindre kompleks.
Hvis det skaber problemer vil det jo være muligt at portere det til et ikke-Latto-baseret tema.
Vi havde tidligere en lang og god diskussion vedr. medudvikling i Ding regi med bl.a. Mette fra Billund hvor der netop er sådan en situation. SASS er selvfølgelig en udfordring her med der er processer så som versionsstyring og deployment, der gør det svært at medudvikle.
Her foreslog jeg selv at et modul så som CSS Injector kunne give mulighed for tilpasning af CSS at bekymre sig så meget om de mere tekniske processer.
Hvis de vil benytte dem i deres egne themes og/eller bidrage til Core skal de. Det er jo ikke et krav.
Samtidig ser vi også et ryk imod CSS preprocessors generelt og SASS specifikt i Drupal theming miljøet, så jeg ser det som sandsynligt at det er noget folk vil skulle forholde sig til før eller siden.
Vores nuværende sæt af værktøjer (drush, git etc.) viser at det er en barriere, der skal overskrides lige meget hvad.
Som ved al anden kode, hvor der tilføjes abstraktionslag, er det selvfølgelig en udfordring, men det kan også gøre ting meget mere overskueligt. Det handler om udviklernes kompetencer.
Latto...
Hvad betyder Latto? Står Latto for noget?
Vil det ikke være problematisk, at have vores eget theme indenfor folkebibliotekerne i Danmark? Her tæmker jeg på om vi ikke mister fordelene ved det store fællesskab og de muligheder det giver os i T!NG for at udnyttes andres gode idéer og kræfter.
Kommer vi i TING ikke til at suboptimerer ved at have vores eget theme, som ingen andre end interessenterne til folkebibliotekerne i DK vil bidrage til?
Det skal siges, at jeg godt kan lide hovedlinjerne i beskrivelsen af baggrunden for Latto, så mine spørgsmål skal blot ses som mine bekymringer for om valgene kan bære på sigt.
Latto
Latto? to tal