allan ebdrup bloghoved ny

Undgå jQuery (DOM-selectors) i tykke JavaScript applikationer

Noget af det der virkelig har givet jQuery og dens medsøstre vind i sejlene, er deres DOM-selectors. Browseren har sine egne DOM-selectors indbygget, som fx getElementById og getElementsByTagName. JavaScript-biblioteker som jQuery udvider dette koncept kraftigt. En DOM-selector er basalt set muligheden for at udvælge en eller flere HTML-noder fra sit dokument. Fx udvælge alle HTML-noder i DOM?en, der har en bestemt CSS-klasse. jQuery kan udvælge HTML-noder på alle mulige andre måder. Når man har udvalgt sig sine noder, kan man lave en masseopdatering af dem, fx tilføje en CSS-klasse, collapse dem, attache events til dem eller noget helt fjerde.
 
Når jeg koder tykke klienter, undgår jeg fuldstændigt at bruge DOM-selectors. Jeg opbygger DOM?en programmatisk og pakker alle mine HTML-noder ind i et abstraktionslag. Jeg har bygget store applikationer fuldstændigt uden brug at DOM-selectors.

 
 
Hvorfor så undgå selectors der arbejder direkte på DOM'en'

  1. **Ingen abstraktion**. Når du bruger de selectors, der findes i dag, arbejder du direkte på DOM'en. Hvis du skal bygge tykke klienter i JavaScript, er det min påstand, at det er nødvendigt med et abstraktionslag over DOM'en. Det er selvfølgeligt, at alle de små browserforskelle skal abstraheres væk i dette lag, men som det vigtigste, kan du indføre dine egne koncepter i dit abstraktionslag. Jeg har for eksempel givet alle mine HTML-noder mulighed for at have en header og/eller en footer - denne abstraktion kan blive ødelagt af at bruge DOM-selectors.
  2. **Lav robusthed**. Når du bruger DOM-selectors, gør du dig afhængig af HTML-detaljer, som fx hvilken CSS-klasse HTML-noden har, hvilket id den har, eller hvilket tag den og/eller dens forældre har. Hvad nu hvis du vil skifte CSS-klasse, eller skifte tag' Så skal du pludselig rette alle dine DOM-selectors, dvs. din applikationslogik. Hvad nu hvis der er en anden udvikler, der finder på at benytte det samme id til en komponent, han/hun laver i applikationen' Så opstår der en fejl i din del af applikationen. Der bliver en meget tæt kobling mellem de enkelte dele, og applikationen kan nemt gå i stykker på meget uforudsigelige måder. Ting som CSS-klasser og id'er på HTML-noder bør ingen indflydelse have på applikationens funktionalitet overhovedet.
  3. **Performance**. DOM-selectors kan være langsomme. Det kommer blandt andet til udtryk som et kapløb mellem de forskellige JavaScript-biblioteker, om at lave de hurtigste DOM-selectors. Hvis du har et stort HTML- dokument, er der en meget reel risiko for, at din applikation kommer til at køre langsomt. Det betyder, at brugere til sidst lægger mærke til ventetiden under opdateringer. Hvis en opdatering tager mere end 1/10 sekund, vil brugeren lægge mærke til den og opfatte din applikation som sløv. Hvis opdateringen tager over 2 sekunder, skal du til at have en progressbar frem, ellers tror brugeren, at applikationen er gået ned. Hvorfor ikke undgå DOM-selectors helt i stedet'
  4. **Umuligt at teste applikationen uden en DOM**. Når du arbejder direkte på DOM'en i din applikation, bliver det umuligt at teste den uden at der er en DOM. Hvis du er afhængig af en DOM, skal du i princippet teste i alle browsere for at være sikker på, at det virker. Derfor er det en god idé at strukturere din applikation sådan, at en så stor del som mulig er uafhængig af DOM'en. Det kræver, at du ikke bruger selectors, der arbejder direkte på DOM?en, men i stedet arbejder i et højere abstraktionslag.

Jeg tror, at den udbredte brug af DOM-selectors er et udtryk for, at vores JavaScript-biblioteker ikke er særligt modne endnu. Hvad tror du?

Kommentarer (93)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Patrick Cording

Gode argumenter du har. Kan du give et eksempel på, hvad du gør for at undgå DOM selectors? Jeg kan ikke lige gennemskue hvordan en programmatisk DOM ser ud og hvad dit HTML-node abstraktionslag består af, men er meget nysgerrig.

  • 0
  • 0
Per Sikker Hansen

Hvad ligger der i vejen for at bygge et abstraktionslag omkring sine DOM-selectors? Fx skrev jeg på et tidspunkt Tetris i JS, hvor al DOM-manipulation foregik i mit UI-objekt, med UI.spawnBlock(id), UI.deleteBlock(id) som metoder der blev kaldt af fx Tetrimino.moveLeft(). Disse UI-metoder er det eneste der har kontakt til DOM'en, som udgangspunkt via JQuery, men kan i princippet hurtigt skiftes ud til at have kontakt til fx et Canvas, eller måske sågar en Flash-scene, hvis koden blev pumpet ind som ActionScript.

Man kan sagtens abstrahere udenom sine DOM-selectors, uden at nægte sig selv de fordele de giver.

  • 0
  • 0
Allan Ebdrup Blogger

Hvad ligger der i vejen for at bygge et abstraktionslag omkring sine DOM-selectors?

Punkt 2 og 3.

Men det er da bedre end at sylte sin kode ind i DOM selectors. Jeg kunne godt have skrevet lidt om at man kan bruge DOM-selectors pænt og mindre pænt. Jeg valgte at lade være for at gøre bloginlæget kort og fordi min erfaring siger mig at de fleste ikke gør som du har gjort.

  • 0
  • 0
Torben Mogensen Blogger
Engelsk | dansk

node | knude
note | node/note/notat/bemærke

Det er i orden at bruge engelske fagtermer, men så brug også engelsk bøjning: Skriv "nodes" i stedet for "noder" osv., og sammensæt ikke vilkårligt med danske ord såsom i "nodekonstruktør". Allerhelst bør engelske fagtermer -- specielt dem, der kan forveksles med danske ord -- markeres i kursiv, f.eks. "[i]node[/i]".

Og, ja, jeg er en slags skolelærer, så jeg må godt være sprogrygter. :-)

  • 0
  • 0
Mikkel Høgh

Allan Ebdrup:

Jeg tror, at den udbredte brug af DOM-selectors er et udtryk for, at vores JavaScript-biblioteker ikke er særligt modne endnu. Hvad tror du?

Jeg tror du er Java-programmør med alle de abstraktionslag du ønsker dig…

Jeg mener ikke det er nødvendigt med flere abstraktionslag. DOM er en ganske udmærket måde at arbejde med HTML/XML.

Mht. robusthed, er det vel kun et problem hvis man ikke har ordentlig styr på sin markup, aka. dårlig kodedisciplin.

Mht. performance, så er DOM selectors på mange måder som SQL queries at hvis man sørger for at have omtanken med, når man skriver dem, plejer det ikke at give anledning til problemer…

Torben Mogensen:

Og, ja, jeg er en slags skolelærer, så jeg må godt være sprogrygter.

Og nu vi er ved retteriet, så hedder det vel sprogrøgter :)

  • 0
  • 0
Allan Ebdrup Blogger

Jeg tror du er Java-programmør med alle de abstraktionslag du ønsker dig

Jeg har engang da jeg gik på Uni skrevet et enkelt Java-program, ellers er det ikke noget jeg beskæftiger mig med. Og jeg vil sådan set bare have et enkelt abstraktionslag.

Mht. robusthed, er det vel kun et problem hvis man ikke har ordentlig styr på sin markup, aka. dårlig kodedisciplin.

Det er ikke hvad jeg ser. Jeg har for eksempel kigget på tykke klienter der har fortryd funktionalitet, i forbendelse med mit blogindlæg.
http://www.version2.dk/artikel/9808-hvad-blev-der-af-fortryd
Det er utroligt hvordan de allesammen har fejl - Et typisk eksempel på implementationer der er bundet til DOM uden abstraktion og så går det galt næste hver gang.
Det handler om at man ikke kan hacke sig igennem tilværelsen hvis man skal bygge forretningskritiske systemer.

  • 0
  • 0
Kim Dalsgaard

Det handler om at man ikke kan hacke sig igennem tilværelsen hvis man skal bygge forretningskritiske systemer.

Nej, det handler derimod om at man ikke kan abstrahere sig ud af virkeligheden, hvis man vil bygge robuste forretningskritiske systemer!

Sidste store katastrofe var netværket (RPC), og nu er du så efter DOM'en.

  • 0
  • 0
Mikkel Høgh

Jeg har engang da jeg gik på Uni skrevet et enkelt Java-program, ellers er det ikke noget jeg beskæftiger mig med.

Fair nok, det var bare et gæt :)

Jeg har for eksempel kigget på tykke klienter der har fortryd funktionalitet, […]
Det er utroligt hvordan de allesammen har fejl - Et typisk eksempel på implementationer der er bundet til DOM uden abstraktion og så går det galt næste hver gang.

Det kan godt være det er mig der er langsom, men jeg ser ikke helt koblingen mellem implementering af fortryd-funktionalitet og hvordan man addresserer markup.

Det handler om at man ikke kan hacke sig igennem tilværelsen hvis man skal bygge forretningskritiske systemer.

Det lader til at din underliggende præmis er at hvis man ikke bruger et eller andet udefinerbart abstraktionslag, og i stedet laver HTML og JavaScript der passer sammen, så gør man ikke sit arbejde ordentligt.
Jeg er, som fremgår af tidligere bemærkninger, ikke enig.

Jeg bryder mig ikke om værktøjer som ASP.NET Web Forms eller andre værktøjer som forsøger at lade som web ikke er web og ikke består af en skøn kombination af HTML, CSS og JavaScript.

Hvis man ikke bryder sig om HTML, CSS og JavaScript kan jeg selvfølgelig godt se at det er rart med værktøjer som abstraherer disse væk, så man ikke får beskidte fingre. Men hvis man har det sådan, så ville jeg mene at man skulle holde sig væk fra web-apps.

  • 0
  • 0
Martin Kofoed

Det handler om at man ikke kan hacke sig igennem tilværelsen hvis man skal bygge forretningskritiske systemer.

Så jQuery og deslige er kendetegnet ved kun at understøtte hastigt sammenhackede, ikke-forretningskritiske systemer eller hvad..?

Jeg er ikke enig. Jeg elsker jQuery og dens måde at lave DOM-trylleri på, men jeg ser det som en snitflade mellem UI og backend. Alt det forretningskritiske har naturligvis intet med UI'et at gøre. DET er abstraktionen. Jeg har ikke brug for at kunne ændre elementers ID, det er ligesom en del af designet, at man anvender unikke ID'er. Ligger det ikke også i termen "ID"? Jeg bygger eksempelvis heller ikke et abstraktionslag omkring persistensdelen af en applikation, således at jeg kan muntre mig med at lave om i databasens unikke nøgler. Det ville være nytteløst.

"Getting things done" skal i øvrigt ikke altid forveksles med "at hacke sig gennem tilværelsen". Uforståelige abstraktioner er en klods om benet på at få ting gjort, og derfor fejler massevis af teoretiske, akademiske abstraktionsteorier når det kommer til real-life anvendelse.

  • 0
  • 0
Allan Ebdrup Blogger

Nej, det handler derimod om at man ikke kan abstrahere sig ud af virkeligheden, hvis man vil bygge robuste forretningskritiske systemer!

Nu kan abstraktion jo være mange ting, sidder du fx og tænker over hvordan de enkelte gates i transistorene i din computerchip virker når du koder?
Selv jQuery er en abstraktion over HTML dokumenter.
Så du må være lidt mere konkret når du har så hård kritik af mit ønske om abstraktion, jeg tror du ligger noget i det jeg skriver der ikke er belæg for.
Bruger du fx aldrig JavaScript objekter?
Kan du ikke se at eksemplet som Per Sikke Hansen kommer med er en god abstraktion?

Leaky Abstractions er en af du største trusler mod robust software, og at prøve at fjerne DOM'en fra en web app vil helt sikkert blive hullet som en si.

Jeg siger ikke du skal fjerne DOM'en (så er der jo ikke meget web-applikation tilbage).
Det jeg taler om er at undgå at du fx attacher events til dit HTML dokument udfra en forudsætning om at de skal attacheds på alle divs i divs der er under et P-tag, med id "myId". Den slags kode ser jeg desværre alt for ofte.

  • 0
  • 0
Allan Ebdrup Blogger

Så jQuery og deslige er kendetegnet ved kun at understøtte hastigt sammenhackede, ikke-forretningskritiske systemer eller hvad..?

Det er sat på spidsen, men mange bruger jQuery uden fornuftige abstraktioner. Så din logik for at attache events fx bliver afhængig af at det du skal attache til ligger som en div med CSS klasse "myClass", og så er svaret til dit spørgsmål: Ja.

Jeg har ikke brug for at kunne ændre elementers ID, det er ligesom en del af designet, at man anvender unikke ID'er. Ligger det ikke også i termen "ID"?

Hvordan sikrer dig at fx elementr i en liste ikke får samme id? Har du noget funktionalitet der holder styr på det? Hov så er du allerede i gang med at bygge din abstraktion.

Det ser ud somom der er noget historik i brugen af ordet abstraktion jeg ikke har taget hensyn til. Det virkes som om i lægger noget i min brug af det ord der ikke er belæg for.

  • 0
  • 0
Allan Ebdrup Blogger

Det lader til at din underliggende præmis er at hvis man ikke bruger et eller andet udefinerbart abstraktionslag, og i stedet laver HTML og JavaScript der passer sammen, så gør man ikke sit arbejde ordentligt.
Jeg er, som fremgår af tidligere bemærkninger, ikke enig.

Ja, jeg kan godt se at mit abstraktionslag har fået folk op af stolen. Det jeg taler om af abstraktion, er en abstraktion der er god nok til at du ikke er afhængig af DOM-selectors. Og så bør du udskille den kode der direkte interagerer med DOM'en. Du vil selvfølgeligt stadig have en dyb afhængighed og interaktion med DOM'en i din kode. Jeg taler ikke om at indføre et generelt abstraktionslag som alt din kode skal snakke med DOM'en gennem.

  • 0
  • 0
Kim Dalsgaard

Nu kan abstraktion jo være mange ting, sidder du fx og tænker over hvordan de enkelte gates i transistorene i din computerchip virker når du koder?

Jeg har ikke noget mod abstraktioner - de skal bare være solide og nødvendige. Har det f.eks. rigtig fint med IP, TCP, HTTP og mange andre gode ting - ser bare ingen grund til at lægge 'hjemmerullede' (og potentielt 'leaky') abstraktioner ovenpå.

Selv jQuery er en abstraktion over HTML dokumenter.

I jQuery glemmer man aldrig at man koder HTML og JavaScript, det er nøglen til dets success.

Bruger du fx aldrig JavaScript objekter?

Jeg bruger gerne objekter, men aldrig disse her JavaScript pseudo-klasser som visse frameworks stiller til rådighed.

Og fortæl mig så lige hvorfor

<person>
<name>Kim</name>
...

er så meget mere 'enterprisey' end

<div class='person'>
<div class='name'>Kim</div>
...

  • 0
  • 0
Thomas Christensen

Min erfaring med udviklere er, at de (vi) gerne vil have abstraktioner til domæner vi ikke er fortrolige med. Derfor vil .NET- eller Java-udvikleren gerne have abstraheret både html/css/javascript og databasen/sql væk. Det medfører desværre applikationer, der er mildest talt klodsede i brugergrænsefladen og som performer dårligt mht. data I/O.

Hvordan har vi det med løsninger, der skal abstraherer forretningslogik-koden væk (4G-værktøjer)?

Så jeg tror dit ubehag med dom-selectere og andet snask skyldes en ulyst til at blive fortrolig med den øverste del af stacken i web-applikationer.

  • 0
  • 0
Michael Mortensen

Og fortæl mig så lige hvorfor

<person>
<name>Kim</name>
...

er så meget mere 'enterprisey' end

<div class='person'>
<div class='name'>Kim</div>

Når jeg ser forslag som dette, så bifalder jeg helt naturligt kreativiteten på samme linie som udviklere der implementere IDisposable ukritisk, fordi de så kan indkapsle deres kode i et using statement, men uden hensynstagen til interfacet's egentlige virken og signal til udvikleren.

Hvor vil jeg hen med dette?
Jo, dit eksempel beskriver data; data som ikke har nogen relation til en UI-relateret visning.

Hvorfor?
Ligesom IDisposable eksemplet, så signalere du til brugeren/systemet en ting, men benytter den til noget andet som KAN have nogle uheldige konsekvenser - det mener jeg er en meget uheldig vej at gå.

Men altså .. bifald til kreativiteten ;-)

  • 0
  • 0
Allan Ebdrup Blogger

Og fortæl mig så lige hvorfor

<person>
<name>Kim</name>
...

er så meget mere 'enterprisey' end

<div class='person'>
<div class='name'>Kim</div>

Når vi snakker enterprise snakker vi også genbrugelige komponenter. Hvis din person-div indeholder et komponent skrevet af en anden udvikler og denne anden udvikler også benytter class='person', har du lige ødelagt din applikation, hvis der er en selector der leder på class='person'.
Derudover er der en tendens til at css klasserne bruges til layout samtidigt. Hvad så når du vil have forskelligt layout der gør at du ikke vil have person css-klassen på din div mere?

  • 0
  • 0
Allan Ebdrup Blogger

Så jeg tror dit ubehag med dom-selectere og andet snask skyldes en ulyst til at blive fortrolig med den øverste del af stacken i web-applikationer.

Slet ikke, jeg drømmer W3C DOM når jeg sover. Tro det eller lad være, jeg mener faktisk ikke vi har brug for DOM-selectors og jeg ved at man sagtens kan klare sig uden, når man bygger tykke browser applikationer. Men vi får jo at se om 10 år hvem der fik ret :-)

  • 0
  • 0
Jimi Hansen

Allan's indlæg lugter af at han er en programmør der har kastet sig over webudvikling fra en ren programmør-vinkel, uden megen viden om web.

Har set en del tåbeligheder på den konto gennem årene. Webdesignere er ofte bedre til at udvikle webløsninger end konventionelle programmører.

  • 0
  • 0
Michael Mortensen

Jeg behøver ikke tage Allan i forsvar, men han er en yderst kompetent (og sjov) personlighed, som både inkludere hardcore web-udvikling samt fornuftige tanker og implementering af eks. Enterprise Arkitektur.

Naturligt nok så vokser Allan med opgaverne og erfaringen, og kan dermed tillade at udfordre os andre i vores tilgang til tingene :-)

  • 0
  • 0
Kim Dalsgaard

Hvis din person-div indeholder et komponent skrevet af en anden udvikler og denne anden udvikler også benytter class='person', har du lige ødelagt din applikation, hvis der er en selector der leder på class='person'.

Hvis dit person-tag indeholder et komponent skrevet af en anden udvikler og denne anden udvikler også benytter tagget person, har du lige ødelagt din applikation, hvis der er et xpath-udtryk der leder efter person tagget.

Det handler om context - jeg vil naturligvis ikke anvende en selector på hele siden hvis jeg ikke kendte til dens oprindelse - selectoren skal selvfølgelig begrænses til det kendte/relevante.

  • 0
  • 0
Allan Ebdrup Blogger

Allan's indlæg lugter af at han er en programmør der har kastet sig over webudvikling fra en ren programmør-vinkel, uden megen viden om web.

Har set en del tåbeligheder på den konto gennem årene. Webdesignere er ofte bedre til at udvikle webløsninger end konventionelle programmører.

Hehe, det er sjovt som folk skal gætte på mine kundskaber og erfaringer fordi jeg ikke kan lide jQuery.

Det jeg taler om er at udvikle en ny google maps, eller en applikation med en kompleksitet som google maps. Det tror jeg ikke du skal sætte webdesignere til.

  • 0
  • 0
Jacob Christian Munch-Andersen

Der er altså også mange webdesignere som har store problemer med at skrive rigtig kode, det bliver sjældent pænt hvis de skal lave lidt mere avancerede sider. Selv kalder jeg mig webprogrammør, jeg håber at det navn har den korrete karmakombination som gør at jeg hverken falder i den ene eller den anden grøft.

Hvad der er god kodestil er ofte et præferencespørgsmål, mange af de ting som er nævnt her vil jeg i hvert fald mene falder i den kategori.

Personligt bruger jeg stort set konsekvent id/getElemenetById til at navigere i DOMen, og CSS skriver jeg enten inline eller vha. klasser, alt efter hvor stort genbrugspotentialet er.

Hvis man arbejder sammen med andre må man jo altid på et eller andet plan koordinere, det bør ikke være super svært at indføre navngivningskonventioner som forhindrer sammenfald selvom alle arbejder i samme scope.

  • 0
  • 0
Peter Müller

Som webudvikler med flere års erfaring i udvikling af tykke javascript klienter kan jeg kun give Ebdrup fuldstændig ret.

Når man opbygger sin DOM i javascript, så er der absolut ingen årsag, andet end dovenskab, for at spørge DOM'en on noget som helst løbende. Det er dig der har bygget DOM'en, du har allerede referencer til alle de ting du skal bruge, bare du huske at gemme dem imens du bygger DOM'en.

Det morer mig at så mange 'webudviklere' i denne tråd nedgør prøgrammørindgangsvinklen til webudvikling. Jeg kan kun håbe at I smider frygten for det nye, og lige sætter jer ned og laver et par hastighedsmålinger. I kan kun blive klogere.

Det kan sågar i flere tilfælde godt betale sig slet ikke at rode rundt i den eksisterende DOM man har bygget, men blot lave en komplet udskiftning af hele molevitten ved en opdatering af større mængder af DOM. Her kan jeg anbefale at man kigger på antallet af browser reflows man udløser ved sine opdateringer. Hvis du laver mere end ét, så kan du ofte spare ved at gentegne det hele i stedet. DOM-traversering og reflows er meget dyre operationer, selvom jQuery har gjort dem usandsynlig nemme.

Til jQuerys forsvar, så har de i det mindste lavet et let interface til event delegation i stedet for event handling på et utal af knuder. Nu mangler den almene webudvikler bare at opdatere sin viden om hvor flaskehalsene ligger.

  • 0
  • 0
Allan Ebdrup Blogger

Det handler om context - jeg vil naturligvis ikke anvende en selector på hele siden hvis jeg ikke kendte til dens oprindelse - selectoren skal selvfølgelig begrænses til det kendte/relevante.

1) Du laver din person-div
2) 6 mnd senere sættens en anden udvikler til at tilføje en kommentar komponent (div) under hvert person-div. Dette kommentarfelt benyttes 50 andre steder i applikationen
3) 6 mnd senere er der en udvikler der har fået opgaven at få kommentarfeltet til at have samme styling som person div-en og tilføjer class='person', Han får ikke testet alle 50 steder kommentarfeltet benyttes og din side fejler.

Det sker ikke med XML fordi der er du opmærksom på context (XSD), men med HTML kan alt lade sig gøre.

  • 0
  • 0
Kim Dalsgaard

6 mnd senere er der en udvikler der har fået opgaven at få kommentarfeltet til at have samme styling som person div-en og tilføjer class='person', Han får ikke testet alle 50 steder kommentarfeltet benyttes og din side fejler.

Den slags kollegaer har jeg ikke - har du?

  • 0
  • 0
Allan Ebdrup Blogger

Det kan sågar i flere tilfælde godt betale sig slet ikke at rode rundt i den eksisterende DOM man har bygget, men blot lave en komplet udskiftning af hele molevitten ved en opdatering af større mængder af DOM. Her kan jeg anbefale at man kigger på antallet af browser reflows man udløser ved sine opdateringer. Hvis du laver mere end ét, så kan du ofte spare ved at gentegne det hele i stedet. DOM-traversering og reflows er meget dyre operationer, selvom jQuery har gjort dem usandsynlig nemme.

Du kan undgå reflows ved at hive noden ud af dokumentet, lave alle dine opdateringer, og så indsætte noden igen. (kunne være body noden)

  • 0
  • 0
Allan Ebdrup Blogger

Den slags kollegaer har jeg ikke - har du?

Tja hvis du får webdesignere til at kode din applikation, som Jimmi Hansen foreslog, kan det være det sker.
Jeg har været så mange steder, at jeg ikke tør spå så meget om hvilke folk der skal rette i det der bliver produceret. Så hellere tage sine forholdsregler og undgå at problemet kan opstå.

  • 0
  • 0
Allan Ebdrup Blogger

Hvis man arbejder sammen med andre må man jo altid på et eller andet plan koordinere, det bør ikke være super svært at indføre navngivningskonventioner som forhindrer sammenfald selvom alle arbejder i samme scope

Det kan jo være at du køber komponenter der løbende bliver opdateret og ændrer sig, hyrer konsulenter/freelancere der ikke lige bliver 100% opdateret på ens standarder, eller nye folk der lige skal ind i tingene.
Så heller have en metode der helt elliminerer problemet.

  • 0
  • 0
Allan Ebdrup Blogger

Det er jeg klar over. Den typiske jQuerybruger er dog ikke.

OK sorry :-), det var bare fodi du skrev at du vile generere det hele forfra. Det er egentligt mærkeligt at jQuery ikke har nogle hjælpefunktioner til at undgå reflow, det ville jeg tro den havde. Det er da oplagt at den skal have det.

  • 0
  • 0
Peter Müller

det var bare fodi du skrev at du vile generere det hele forfra. Det er egentligt mærkeligt at jQuery ikke har nogle hjælpefunktioner til at undgå reflow, det ville jeg tro den havde. Det er da oplagt at den skal have det.

Somme tider er det lettere at generere alting forfra. Du har jo allerede logikken til det. Så hvorfor også implementere logikken til at redigere i det genererede i stedet for bare at generere det igen med de relevante opdateringer inkluderet, forudsat at der intet overhead er ved det?

De fleste normale DOM-manipulationer der foregår i den samme arbejdsgang i javascript event køen trigger kun ét reflow også hvis flere elementer manipuleres samtidigt.

Der er dog undtagelser man let kan ramle ind i, feks med flere samtidige animationer som er hver deres arbejdsgang, og dermed tvinger browseren til reflow efter hver arbejdsgang. Man kan også risikere at tvinge løbende reflows ved at lave målinger på DOM'en eller modificere en scrollbars srolltop midt i en arbejdsgang.

Der er mange faldgruber. Jeg glæder mig til debuggingværktøjerne begynder at tage antallet af reflows op som et optimeringkriterie.

  • 0
  • 0
Jacob Christian Munch-Andersen

Når man opbygger sin DOM i javascript

Den praksis er jeg så vidt muligt holdt op med at bruge, jeg synes det giver et bedre overblik og renere kode at skrive indholdet som statisk HTML og så gemme hvad der ikke skal vises. Selvfølgelig kan man ikke lave alt på den måde, men der er ofte en ret stor mængde rammearbejde som metoden passer fint til.

  • 0
  • 0
Peter Müller

Den praksis er jeg så vidt muligt holdt op med at bruge, jeg synes det giver et bedre overblik og renere kode at skrive indholdet som statisk HTML og så gemme hvad der ikke skal vises. Selvfølgelig kan man ikke lave alt på den måde, men der er ofte en ret stor mængde rammearbejde som metoden passer fint til.

Det afhænger i høj grad af hvordan ens data ser ud. I den applikation jeg arbejder på for tiden, er den tilgangsvinkel ikke brugbar. I praksis er det dog også et ganske brugbart pattern såfremt man gemmer sine dom-referencer og ikke querier hele tiden.

  • 0
  • 0
Jacob Christian Munch-Andersen

[quote]Hvis man arbejder sammen med andre må man jo altid på et eller andet plan koordinere, det bør ikke være super svært at indføre navngivningskonventioner som forhindrer sammenfald selvom alle arbejder i samme scope.

Det kan jo være at du køber komponenter der løbende bliver opdateret og ændrer sig, hyrer konsulenter/freelancere der ikke lige bliver 100% opdateret på ens standarder, eller nye folk der lige skal ind i tingene.
Så heller have en metode der helt elliminerer problemet.[/quote]Du mener at du kan sikre dig mod at andre mennesker kan ødelægge din kode? Du må have fundet et stykke af den hellige gral.

I øvrigt, du har nu skrevet en hel masse om hvad man ikke skal gøre, men jeg har ikke helt fattet hvad du mener man skal gøre. Bygge hele sin DOM dynamisk som Peter Müller åbenbart gør?

  • 0
  • 0
Allan Ebdrup Blogger

jeg synes det giver et bedre overblik og renere kode at skrive indholdet som statisk HTML og så gemme hvad der ikke skal vises.

Det er oplagt at man skal have et templating system for at bygge applikationer. Men der er lang vej fra et templating system, til at bygge hele sin applikation op omkring DOM-selectors.

  • 0
  • 0
Allan Ebdrup Blogger

I øvrigt, du har nu skrevet en hel masse om hvad man ikke skal gøre, men jeg har ikke helt fattet hvad du mener man skal gøre. Bygge hele sin DOM dynamisk som Peter Müller åbenbart gør?

Jeg har skam ikke alle svarene, jeg synes bare der er problemer ved at benytte jQuery fuldstændig ukritisk. Det har jeg så sat på spidsen i mit blog-indlæg.
En måde er at opbygge sin DOM dynamisk, det er rigtigt godt til nogle typer af applikationer.
Når man har brug for templating skal man tænke sig om og være opmærksom på de problemstillinger jeg beskriver i blogindlæget. Det vil forme den templating mekanisme du benytter.

  • 0
  • 0
Allan Ebdrup Blogger

Du mener at du kan sikre dig mod at andre mennesker kan ødelægge din kode? Du må have fundet et stykke af den hellige gral.

Nej, jeg påpeger bare at css klasser er født til at lave layout. Hvis vi begynder at bruge dem til at være bærende for funktionalitet, kan der nemt opstå problemer.

  • 0
  • 0
Kim Dalsgaard

Nej, jeg påpeger bare at css klasser er født til at lave layout. Hvis vi begynder at bruge dem til at være bærende for funktionalitet, kan der nemt opstå problemer.

Fra HTML5 spec'en

The attribute, if specified, must have a value that is a set of space-separated tokens representing the various classes that the element belongs to.
...
There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.

  • 0
  • 0
Allan Ebdrup Blogger

Du angriber id i samme åndedrag, det er her jeg ikke rigtigt kan følge dig.

Det er når du bygger din DOM dynamisk, så er der ikke nogen grund til at benytte id. Når du har en stor dynamisk applikation bygget af mange udviklere kan det være en fordel at undgå antagelser om hvilket id man kan benytte.

  • 0
  • 0
Allan Ebdrup Blogger

There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.

Ting kan have samme "nature", men det er et sundt princip HTML5 har.

  • 0
  • 0
Allan Ebdrup Blogger

Ting kan have samme "nature", men det er et sundt princip HTML5 har.

For at uddybe. I person-klasse eksemplet fra før, kunne kvikler vurdere at kommentarfeltet havde "person-nature", fordi det er et personligt kommentarfelt.

  • 0
  • 0
Kim Dalsgaard

For at uddybe. I person-klasse eksemplet fra før, kunne kvikler vurdere at kommentarfeltet havde "person-nature", fordi det er et personligt kommentarfelt.

Nej, man 'tagger' ikke et kommentarfelt med 'person' - det er og bliver sjusk!

Desuden bruger man typisk 'nested selectors', f.eks.

$("div.person-list > div.person")

og måske med en id som 'guard'

$("#my-part div.person-list > div.person")

hvis ikke man bruger relative søgninger

myPart.find("div.person-list > div.person")

  • 0
  • 0
Allan Ebdrup Blogger

Nej, man 'tagger' ikke et kommentarfelt med 'person' - det er og bliver sjusk

Det kunne være der er maskingenererede kommentarer og personlige kommentarer. Først får kommentag div-en klassen "comment", så skal de maskingenererede have yderligere kvalificering så de får i tilgift klassen "machine", og så skal de personlige kvalificeres og får klassen "person".

$("div.person-list > div.person")

Kommentar div'erne er blevet indsat her, mellem person-div'erne.

  • 0
  • 0
Carsten Sonne

En gammel kollega, der var blevet pænt træt af at vedligeholde dårligt designede webapplikationer sker engang denne lille 'Best Pratice' guide.

Jeg har postet den før, men jeg griner hver gang jeg læser den.


  1. Use LOTS of global variables. Distribute globals evenly between session, application, cookies and usertables and use describing names like “Counter”, “Value”, “Action” or “ID”.

  2. Make sure that every part of the code and database depends heavily on as many globals as possible and make sure to modify them as many places as possible. This is called flexible design.

  3. Don’t hesitate to reuse functions or part of functions for completely different purposes. It’s better to combine several functions into one BIIIG function and pass the desired purpose as a combination of several arguments and/or globals. This is called efficient use of code.

  4. Names all your database objects throuroghly describing what they are instead of what they are used for. Save place by abbreviating the purpose of the objects instead. Good naming examples are: “spx_Get_Adminpage_Data_ usr_old3”, “spx_Get_ Adminpage Data uw_ test3_dontdelete”. This hints the reader of your code with valuable information like “I’m calling a stored procedure that returns data, to the page named “Adminpage” (Which by the way the reader is probably already located at, although [Pagename] shouldn’t restrict you to call the procedure from only that page)

  5. But most importantly make sure all procedures exists in several almost identical versions. By never deleting anything you ensure stability and backwards compatibility of your product.

  6. Take advantage of the great features of webdesign. HTML can be modified from practically everywhere. You can create it dynamically from a database, hardcode it in a webpage, generate it from ASP and even alter it on the fly using client side javascript, which can be created dynamically as well. Not a single tag should be displayed without involving all four technologies at least once.

  7. Never build your HTML from ground and up. Instead have a basic template and modify it by swapping variable references, ids, tags and injecting javascript. Functions like Replace, InStr are great for building “dynamic” webpages. Such techniques demonstrates your superior knowledge of webprogramming and it’s fun to watch the baffled expression of your colleagues as they try to figure out your brilliant code.

  • 0
  • 0
Kim Dalsgaard

Det kunne være der er maskingenererede kommentarer og personlige kommentarer. Først får kommentag div-en klassen "comment", så skal de maskingenererede have yderligere kvalificering så de får i tilgift klassen "machine", og så skal de personlige kvalificeres og får klassen "person".

Så bør man tildele class-attributerne "comment machine-comment" og "comment person-comment". Jeg kan jo heller ikke sætte mine alufælge til salg under bil.

Ham der sætter kommentar div'en med class="person" ind mellem person-div'erne, ham kan ingen magt hjælpe.

  • 0
  • 0
Jimi Hansen

Det er når du bygger din DOM dynamisk, så er der ikke nogen grund til at benytte id.

Netop. Det der er burhønse-logik. Hvis man allerede kender de nodes man skal have fat i (fordi man netop har bygget dem), så gemmer man selvfølgelig en liste over dem i en variabel, fremfor at bruge langsom DOM-traversing til at finde dem igen. Det er børnehave-viden hos Javascript-folk, se fx. punkt 6 på de her 10 jQuery tips:

http://net.tutsplus.com/tutorials/javascript-ajax/10-ways-to-instantly-i...

Alle ordentlige webdesignere kender også princippet bag Unobtrusive JavaScript, hvor man sørger for at den basale funktionalitet (om muligt) ligger i ren HTML, og så er man nødt til at tage udgangspunkt i den eksisterende DOM, fremfor at bygge den fra grunden af.

Så brug endelig jQuery og DOM-selectors, det er godt håndværk for webdesignere...

http://en.wikipedia.org/wiki/Unobtrusive_JavaScript

Men det er naturligvis en helt anden sag, hvis man laver avancerede applikationer a la Google Maps, som kræver tung Javascript og hvor ren HTML slet ikke kan levere funktionaliteten.

  • 0
  • 0
Carsten Sonne

Applikationer af en vis størrelse bukker under for deres egen vægt hvis ikke der er et minimum at abstraktion.

Den traditionelle løsning er som bekendt en lagdelt applikations arkitektur. Hvis man kender det princip, vil man vide at præsentation og præsentationslogik bør adskilles fra forretningslogik og data access.

At brugerinterfacet er en browser, laver ikke om på det faktum.

En passen abstaktion igennem de forskellige dele af applikationskode gør koden mere vedligeholdelsesvenlig og dermed robust.

Selvfølgelig har abstrabtion nogle tradeoffs, bl.a. performance. Det skal man være 100% bevidst om når man benytter sig af abstraktioner.

  • 0
  • 0
Allan Ebdrup Blogger

Netop. Det der er burhønse-logik, hvis man allerede kender de nodes man skal have fat i (fordi man netop har bygget dem), så gemmer man selvfølgelig en liste over dem i en variabel fremfor at bruge langsom DOM-traversing til at finde dem igen. Det er børnehav- viden hos javascript-folk, se fx. punkt 6 på denne her 10 jQuery tips:

Det har hele tiden være præmissen at du bygger en tyk JavaScript klient hvor du genrerer din DOM via JavaScript. Det mener jeg fremgår af at jeg skriver følgende:

Jeg opbygger DOM’en programmatisk og pakker alle mine HTML-noder ind i et abstraktionslag. Jeg har bygget store applikationer fuldstændigt uden brug at DOM-selectors.

Jeg taler om tykke JavaScript klienter hvor JavaScript er et krav.

Du kan se listen med 4 "problemer" med DOM-selectors som det man vinder ved at gøre det på denne måde. Det er jeg ikke sikker på alle har tænkt over, men hvis du har så fint.

  • 0
  • 0
Allan Ebdrup Blogger

Så bør man tildele class-attributerne "comment machine-comment" og "comment person-comment". Jeg kan jo heller ikke sætte mine alufælge til salg under bil.

Enig, sådan virker det i dette tilfælde.
Hvad så med personen der bliver vist under kommentaren? Skal han hedde "person-comment-person"? Et eller andet sted må man lave shortcuts i navnestandarden, man kan ikke fuldt kvalificere alting, og der er et potentiale for at det kan gå galt. Det virker somom du har en solid taxonimi du arbejder udfra, men hvis reglen er at du skal beskrive ting udfra deres "nature", kan jeg ikke se hvorfor man ikke kan sige at kommentarfeltet har "person" nature. Hvilke principper arbejder man udfra så der aldrig opstår tvivlstilfælde?

  • 0
  • 0
Jimi Hansen

Det har hele tiden være præmissen at du bygger en tyk JavaScript klient hvor du genrerer din DOM via JavaScript.

Hvis man er progrømmer der laver den slags, skulle det vel også gerne være MEGET indlysende, at man ikke laver 1000 komplekse DOM-traverseringer. Det er det i hvertfald for en dum webdesigner som mig.

Hvis det her virkelig er en stor åbenbaring for programmører, så fastholder jeg at I skulle tage at læse nogle grundbøger i webdesign, før I går i gang :)

  • 0
  • 0
Kim Dalsgaard

Jeg nåede ikke at kommentere på de fire hvorfor'er, så det vil jeg gøre nu.

Ad 1) Jeg mener ikke at der er behov for 'hjemmerullede' abstraktionslag.

Ad 2) Tager man sig tid til at lære at lave semantiske html-dokumenter, så får man en meget robust løsning.

Ad 3) At bygge dokumenter vha. javascript giver en meget ringe performance. Det er meget hurtiger at indsætte html ved hjælp af 'innerHTML' og lignende.

Ad 4) Der findes gode 'headless' test-frameworks der 'mock'er DOM'en.

Vil man vide mere kan jeg anbefale 'Secrets of the JavaScript Ninja' (Early Access) af John Resig (manden bag jQuery).

  • 0
  • 0
Lars Ole Belhage

Kan anbefales (som baggrundslæsning):

http://qooxdoo.org/

Citat:
qooxdoo is a comprehensive and innovative framework for creating rich internet applications (RIAs). Leveraging object-oriented JavaScript allows developers to build impressive cross-browser applications. No HTML, CSS nor DOM knowledge is needed.

Specielt den sidste sætning må glæde flere af jer ;)

  • 0
  • 0
Kim Dalsgaard

Skal han hedde "person-comment-person"?

Ønsker man specifikt at fange personer under personkommentarer så gøres det med

$("person-comment person")

Hvilke principper arbejder man udfra så der aldrig opstår tvivlstilfælde?

'Is a'-relationer - der er f.eks en 'is a' relation mellem 'venstre arm' og 'arm', men ikke mellem 'underarm' og 'arm'

  • 0
  • 0
Allan Ebdrup Blogger

'Is a'-relationer - der er f.eks en 'is a' relation mellem 'venstre arm' og 'arm', men ikke mellem 'underarm' og 'arm'

Jeg tror ikke vi kommer det nærmere end at der er en risiko for at venstre arm kan blive indsat under armen.
Men som du skrev:

Ham der sætter kommentar div'en med class="person" ind mellem person-div'erne, ham kan ingen magt hjælpe.

Der måtte jeg grine, altså ikke hånligt :-)

  • 0
  • 0
Allan Ebdrup Blogger

Sidste store katastrofe var netværket (RPC), og nu er du så efter DOM'en.

Jeg ved ikke hvad du mener med at sidste katastrofe var RPC? Men jeg håber det fremgår at jeg intet har imod DOM'en. Jeg anbefaler på det kraftigste at man sætter sig ind i DOM'en og koder op imod den. Det jeg advokerer for er at lag-dele sin applikation. Som også Carsten Sonne Larsen er inde på.

  • 0
  • 0
Kim Dalsgaard

Jeg ved ikke hvad du mener med at sidste katastrofe var RPC?

RPC som i SOAP, DCOM, CORBA mf.

Ikke noget med browser-app's at gøre, men eksempler på hvor galt det kan gå med leaky abstractions.

  • 0
  • 0
Martin Kofoed

Men vi får jo at se om 10 år hvem der fik ret :-)

Jamen, DET tror jeg, at du får! :-)

Fordi: Om 10 år tegner vi grænseflader som vi gjorde i Delphi for over 10 år siden med veludviklede widget-sets direkte på <canvas>. Og jeg tror maksimalt der går 5 år. Inden da skal JSF heller ikke helt afskrives. Jeg har aldrig været den store fan, men man MÅ nu sige, at JSF 2.0 oven på EJB 3.1 og JPA ser lækkert ud!

Under alle omstændigheder bevæger vi os konstant i bedre retning. Men vi kommer jo også fra et katastrofalt udgangspunkt! Jeg skiftede fra Delphi til webudvikling engang i år 2000, og man måtte da knibe sig i armen over det massive tidsforbrug, der blev accepteret på noget så simpelt som en bare rimeligt sammenhængende brugergrænseflade ...

  • 0
  • 0
Allan Ebdrup Blogger

Ad 3) At bygge dokumenter vha. javascript giver en meget ringe performance. Det er meget hurtiger at indsætte html ved hjælp af 'innerHTML' og lignende.

Det er faktisk ikke rigtigt at der performer meget ringe. Det er rigtigt at innerHTML er det hurtigste, men hvis du bygger din documentFragment op udenfor DOM'en og først indsætter når du er færdig med den, performer det faktisk meget godt.
Fx Douglas Crockford anbefaler dette hvis det giver den pæneste kode, og det gør det ofte.

  • 0
  • 0
Kim Dalsgaard

Jeg skal heller ikke sige mig fri at bruge dynamisk indsættelse af DOM-elementer af og til - jeg ville bare sikre mig at det ikke stod alene som 'det sikre valg'.

  • 0
  • 0
Allan Ebdrup Blogger

@Kim
Som jeg kan forstå det kan du godt lide jQuery fordi den faktisk er en bevidst leaky abstraction. De abstractions jeg har lavet over DOM'en er faktisk leaky, men de giver mig ting som cross browser drag & drop, fotter/header noder og lignende. Hvad siger du til leaky abstractions på denne måde? Altså abstraktioner hvor man aldrig glemmer at man arbejder med en DOM men stadig får noget generelt funktionalitet foræret?

  • 0
  • 0
Torben Mogensen Blogger

Og nu vi er ved retteriet, så hedder det vel sprogrøgter :)

Jeg tror, at det var George Bernard Shaw, der konstanterede, at når man skrev for at kritisere en andens sprogbrug, så ville der, uanset hvor umage man gjorde sig, altid være en sproglig fejl i ens eget indlæg.

  • 0
  • 0
Fini Alring

Jeg tror, at den udbredte brug af DOM-selectors er et udtryk for, at vores JavaScript-biblioteker ikke er særligt modne endnu. Hvad tror du?

Man kan også argumentere for at mange udviklere ikke er modne nok til at bruge dem optimalt.

Ligesom et hav af Windows applikationer skrevet i Visual Basic og lign. kan "misbruges" i stor stil til at udvikle ufattelig langsomme og fejlbefængte applikationer så kan det samme selvfølgelig ske med JS og dets biblioteker (jQuery, Prototype, mootools osv..).

Bare fordi man kan gøre noget simpelt er ikke ens betydende med at man bør gøre det, især ikke hvis performance og robusthed skal være i fokus.

Et stort projekt med mange involverede kræver selvfølgelig også nogle guidelines for hvordan ting navngives, delegeres osv..

DOM-selectors kan med fordel bruges i mange sammenhæng, men det kræver selvfølgelig at man kan stole på at ID og CLASS navne bruges korrekt og man laver sin DOM-queries i et begrænset (relevant) område af DOM.

  • 0
  • 0
Allan Ebdrup Blogger

Jeg har rettet titlen på blogindlæget tilbage tid det den oprindeligt var, så det nu hedder at man skal undgå jQuery i tykke JavaScript applikationer. Det var nok en fejl at den ikke hed det hele tiden.
@Fini Alring

Et stort projekt med mange involverede kræver selvfølgelig også nogle guidelines for hvordan ting navngives, delegeres osv.

Ja det håber jeg at vi har fået belyst, det var det der var hensigten.
@Martin Kofoed

Fordi: Om 10 år tegner vi grænseflader som vi gjorde i Delphi for over 10 år siden med veludviklede widget-sets direkte på <canvas>. Og jeg tror maksimalt der går 5 år. Inden da skal JSF heller ikke helt afskrives. Jeg har aldrig været den store fan, men man MÅ nu sige, at JSF 2.0 oven på EJB 3.1 og JPA ser lækkert ud!

Da XAML kom frem tænkte jeg "Nu dræber de Html og JavaScript", da XUL kom frem tænkte jeg: "Nu er det slut med JavaScript og HTML". Jeg er efterhånden holdt op med at tro på at JavaScript og HTML dør foreløbigt, men jeg tror der kommer en fortsat enorm udvikling indenfor de tools vi har til HTML og JavaScript løsninger. Til tykke JavaScript webapplikationer tror jeg at jQuery ryger i svinget på et tidspunkt.

  • 0
  • 0
Allan Ebdrup Blogger

Med den 'track record', så kan jQuery vist godt sove trygt om natten

Jeg tror det er kommet bag på mange hvor længe JavaScript og HTML har overlevet. Der har været mange andre end mig der har troet at det ville blive erstattet af noget andet og bedre, simpelthen fordi det er så ringe. Men det ser ud til at vi ikke får en afløser lige foreløbigt.

  • 0
  • 0
Allan Ebdrup Blogger

Med den 'track record', så kan jQuery vist godt sove trygt om natten ;-)

Jeg sagde jo heller ikke hvor længe tanken strefejede mig. Men du skal jo huske på at det var i tiden før begrebet AJAX var opfundet, og før din så kære jQuery, vi taler IE5.5, der var meget der kunne forbedres.

  • 0
  • 0
Allan Ebdrup Blogger

OK Kim, jeg er spændt på hvordan du vil sno dig uden om den her:

Forretningen beslutter i alt sin visdom at et kommentarfelt skal vises anderledes når der er kommet 100 komentarer. Ved kommentar nummer 100, skal den person vises der har lavet flest kommentarer, sammen med et tal for hvor mange kommentarer han/hun har lavet.

Din kommentar-div har fået person-nature og din selector får pludseligt fat i alle kommentarene også.

Igen er situationen gjort værre af at kommentarfeltet bruges 50 steder, og din side bliver ikke testet, da der ikke er noget logisk sammenhæng med at din selector fejler og det at kommentarfeltet er blevet rettet.
Så din fejl ryger direkte i produktion, ud til kunden.

Du har ingen model der binder dine data og dit view direkte, i stedet knalder du det hele sammen i HTML og selecter på class og krydser fingre for at det går godt.
Man bliver simpelthen nød til at kapsle sine ting bedre ind, hvis man skal have en robust applikation.

  • 0
  • 0
Vijay Prasad

Forretningen beslutter i alt sin visdom at et kommentarfelt skal vises anderledes når der er kommet 100 komentarer.

Rolig nu, der er stadig kun ~80 kommentarer her i tråden :-)

Jeg er i øvrigt ikke helt med på dit eksempel - måske fordi jeg ikke har læst alle indlæg her - men, der er vel ingen regel som siger at man altid har et smukt abstraktionslag, ligesom der ikke er en regel om at man altid har en skod-DOM-struktur at arbejde med.

Mvh,

  • 0
  • 0
Allan Ebdrup Blogger

Oprindeligt spørgsmål af Kim Dalsgaard

Og fortæl mig så lige hvorfor
<person>
<name>Kim</name>
...

er så meget mere 'enterprisey' end

<div class='person'>
<div class='name'>Kim</div>

Der er en DOM selector der udvælger divs med class='person' og fx attacher events til disse divs

Div's skal have en class der svarer til en "Is-a" relation.

Mit modspørgsmål:
Hvad nu hvis vi har som forudsætining at i vores enterprice laver vi genbrugelige komponenter. Et af disse komponenter er et kommentarfelt. Denne komponent benyttes på 50 andre sider.
Så sker der følgende:

1) en udvikler får til opgave at lave kommentare under hver person i ovenstående og indsætter en kommentar-div mellem hver person-div

2) 6 mndr senere beslutter forretningen i alt sin visdom at et kommentarfelt skal vises anderledes når der er kommet 100 komentarer. Ved kommentar nummer 100, skal den person vises der har lavet flest kommentarer, sammen med et tal for hvor mange kommentarer han/hun har lavet. End udvikler retter dette og kommentar-diven bliver til en person-div.

Det resulterer i at siden med en DOM-selector der vælger på class=person får for mange noder med når den vælger og siden fejler.

Min påstand:
Så snart man tænker genbrugelige komponenter og begynder at sætte forskellige ting sammen, som man gør i en "enterprise", dur det ikke at bruge DOM-selectors.

  • 0
  • 0
Kim Dalsgaard

De lyder næsten som om de sætter lighedstegn mellem Enterprise(y) og sjusk?

Når du på den beskrevne måde smider om dig med 'class' attributer, hvad så med din styling. Der kunne være et 'display: none' der har forvildet sig i en (enterprisey) css-fil, som pludselig får vitale dele af siden til at forsvinde.

  • 0
  • 0
Allan Ebdrup Blogger

Når du på den beskrevne måde smider om dig med 'class' attributer, hvad så med din styling.

Jeg kan ikke se at styling har noget med det at gøre? Men skal jeg forstå det således at problemet ikke opstår fordi man er sikret ved at ens styling fanger problemet?

Og jeg forstår ikke hvad der får dig til at sige at jeg smider om mig med class atributter? Jeg har brugt din metode med at lave en "Is-a" relation til det div'en indeholder.

Jeg kunne bare godt tænke mig at kortlægge de regler du arbejder efter der gør at eksemplet er helt hen i vejret? Jeg er nysgerrig.

  • 0
  • 0
Allan Ebdrup Blogger

Hvis følgende selector fanger andet end personer på en personliste, så er der noget helt galt

$(".person-list > .person")

Det kan vi godt blive enige om :-) Nu var præmissen jo at der blev indsat kommentare mellem hver enkelt person (det kræver UI'et), og at disse kommentare af omveje fik klassen person, og så går den i stykker.

Som jeg ser der er der flere strategier man kan vælge
1) Kryds fingre, det sker nok aldrig, ikke særligt "enterprise", og det var det der var præmissen.

2) Hav en global liste over css-classes og hvad de bruges til, den skal også koordineres med eksterne udviklere og de eksterne komponenter man benytter. Men det vil være tungt at vedligeholde og error-prone.

3) Køre en fuld integrationstest af hele ens applikation ved hver release.

4) Lad være med at bruge DOM-selectors så snart man har sat mere end eet komponent sammen i GUI'en, og det kan være svært at spå om hvor man vil indsætte komponeneter i sin GUI.

Uanset hvad man vælger af strategi, skal man være opmærksom på at der er en risiko når man benytter DOM-selectors, for at det går galt på ret uforudsigelige måder.

  • 0
  • 0
Allan Ebdrup Blogger

Mand #1: Din kalender dur ikke!
Mand #2: Hvorfor ikke? Den dur da fint.
Mand #1: Men hvis der kommer to torsdage i den samme uge så bryder den sammen - derfor!

Jeg gætter på at det betyder at du vælger krydse-fingre taktikken.

  • 0
  • 0
Jacob Christian Munch-Andersen

På et eller andet plan må man bare vælge at krydse fingre for at der hverken kommer to torsdage i en uge, eller en anden udvikler og piller uden at teste applikationen. Man kan ikke tage hensyn til alt, hvis man prøver på det, så kommer man aldrig videre med projektet.

Der er mange måder at organisere sine data på, det er meget vigtigere at man bygger et ensartet og gennemskueligt system, end om man vælger den ene eller den anden programmatiske måde at tilgå dem på.

  • 0
  • 0
Jasper Theisen

Jeg bringer sku' en efterlysning efter udviklere der har oplevet to torsdage i en uge. Så må vi se hvor tit det sker :-)

Hvis du kan acceptere to mandage kan jeg skrive under på den:

http://support.microsoft.com/default.aspx?scid=http://support.microsoft....

Jeg husker tydeligt at den gav et par grå hår da chefen kom og med følgende bemærkning: "Din kalender dur ikke!" ;)

  • 0
  • 0
Log ind eller Opret konto for at kommentere