---

Nu har jeg efterhånden kodet en del javascript med en masse
funktioner spredt rundt omkring, men jeg savner en lidt mere
struktureret måde at gøre det på.

Så er jeg stødt på følgende måde at gøre det på, og vil høre hvad
I synes om den?

event = {
add: function(elm, handler, function) {
},
remove: function(elm, handler) {
}
}

event.add(document.getElementById("anything"), "click",
doSomeThing());

Jeg synes umiddelbart metoden ser smart ud, også fordi man får
lavet sin javscript lidt mere objektorienteret?

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

> Så er jeg stødt på følgende måde at gøre det på, og vil høre hvad
> I synes om den?

Og kan det være en ide at gøre det på den måde selv kun ved en
enkelt funktion?

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Lars Olesen <usenet@legestue.net> writes:

> event = {
> add: function(elm, handler, function) {
> },
....
> event.add(document.getElementById("anything"), "click",
> doSomeThing());
>
> Jeg synes umiddelbart metoden ser smart ud, også fordi man får
> lavet sin javscript lidt mere objektorienteret?

Jeg synes umiddelbart at det er en ok måde at organisere sine metoder,
så de ikke alle sammen ligger og flyde i det globale navnerum (men så
er "event" nok et dårligt valgt navn :)

Det er dog ikke spor objektorienteret. Objektet her bliver udelukkende
brugt som et lokalt navnerum (hvis man kan undersætte "namespace" til
det).

En anden, lige så effektiv, måde at gruppere metoder på er at prefixe
navnet:
function event_add(...)...
function event_remove(...)...

Det giver ca. det samme, og er endda nok en anelse hurtigere at slå op
(ikke noget der har praktisk betydning, dog).

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

"Lars" <lsolesen@gmail.com> writes:

> Ok, kan du give et ex på rigtig oop javascript?

Jeg har noget her:
<URL:http://www.infimum.dk/HTML/borderline.js>
(brugt til at tegne vektorgrafik på siden
<URL:http://www.infimum.dk/HTML/rotatingStar.html>, som skal
ses i en standardoverholdende browser - altså *ikke* IE)

Det er ikke vanvittigt kønt (jeg ville ikke skrive det præcist
sådan i dag), men det har en af grundideerne fra objektorientering:
Objekter samler både tilstand og opførsel (metoder) på samme sted.

Det efterligner dog klassebaseret programmering, hvor Javascript
faktisk ikke er et klassebaseret oo-sprog, men et prototypebaseret
oo-sprog [1].

/L
[1] I klassebaserede sprog sker nedarvning mellem klasser, mens
i prototypebaserede sprog sker nedarvning mellem objekter.
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

Lasse Reichstein Nielsen wrote:
> "Lars" <lsolesen@gmail.com> writes:
>
>> Ok, kan du give et ex på rigtig oop javascript?
>
> Jeg har noget her:
> <URL:http://www.infimum.dk/HTML/borderline.js>
> (brugt til at tegne vektorgrafik på siden
> <URL:http://www.infimum.dk/HTML/rotatingStar.html>, som skal
> ses i en standardoverholdende browser - altså *ikke* IE)
>
> Det er ikke vanvittigt kønt (jeg ville ikke skrive det præcist
> sådan i dag), men det har en af grundideerne fra objektorientering:
> Objekter samler både tilstand og opførsel (metoder) på samme sted.
>
> Det efterligner dog klassebaseret programmering, hvor Javascript
> faktisk ikke er et klassebaseret oo-sprog, men et prototypebaseret
> oo-sprog [1].
>

Du har grundlæggende ret, men det er muligt at kontruere objekter i JS
der funktionelt mimder om OOP, at nedarv og polyformi og alt det andet
"sjove" ikke er tilstede, bør ikke afholde en fra at strukturere
scripts. Hvis JS har en seriøs mangel, så er det egentlige
con/destructorer og det er bøvlet at lave dem selv, nogen gange er det
også umuligt.

Event modellen er jeg ikke vild med, den kan meget nemt komme til at
skabe forståelseskonflikter med, feks. onmouseover.

Med venlig hilsen
Johnny Winther Ronnenberg
--
Internettet er for alle!
http://80.62.61.212/webuseability/index.asp

---

"Johnny Winther Ronnenberg" <johnny.winther@XYZ789tdcadsl.dk> writes:

> men det er muligt at kontruere objekter i JS
> der funktionelt mimder om OOP, at nedarv og polyformi og alt det andet
> "sjove" ikke er tilstede, bør ikke afholde en fra at strukturere
> scripts.

Struktur skal man altid have, objektorientering eller ej, og jeg synes
faktisk ikke Javascript gør det nemt nok at strukturere (en simpel måde
at lave lokale variable ville fx være behageligt).

Den prototypebaserede objektorientering *er* en lige så rigtig
objektorientering som den klassebaserede (og Javascript er i godt
selvskab med de to andre (mere eller mindre) kendte prototypebaserede
sprog: Smalltalk og Self). Man skal tænke lidt anderledes end i
klassebaserede sprog, men hvis man kan det (og det kan jeg ikke :)
så skulle det, efter sigende, være ganske smart.

> Hvis JS har en seriøs mangel, så er det egentlige con/destructorer
> og det er bøvlet at lave dem selv, nogen gange er det også umuligt.

Destruktorer findes ikke (men det gør de heller ikke i, fx, Java,
så det kan man lige så godt vænne sig til :).

Konstruktorer ... ja, hvad er sådan nogle egentlig. Det er "metoder"
der sørger for at initialisere et objekt, så det lever op til
de forventninger brugeren har til den type objekter. I et
klassebaseret sprog er det klassen der bestemmer hvad de forventinger
er, men i et prototypebaseret sprog, så vil et nyt objekt automatisk
have de samme egenskaber som den prototype det nedarver fra. Der er
en konstruktor ikke så nødvendig. Javascript tillader dog at man
laver lidt initalisering hver gang man laver et objekt.


> Event modellen er jeg ikke vild med, den kan meget nemt komme til at
> skabe forståelseskonflikter med, feks. onmouseover.

Den er så heller ikke en del af sproget (jeg kan godt lide Javascript,
men jeg er heller ikke vildt begejstret for W3C DOM'en). Javascript
bruges også andre steder end i browsere, hvor "mouseover" ikke giver
så meget mening :)

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

Lasse Reichstein Nielsen wrote:
> "Johnny Winther Ronnenberg" <johnny.winther@XYZ789tdcadsl.dk> writes:
[klip]
> Struktur skal man altid have, objektorientering eller ej, og jeg synes
> faktisk ikke Javascript gør det nemt nok at strukturere (en simpel måde
> at lave lokale variable ville fx være behageligt).
[klip]

For at lave en lokal variabel, skal man skrive 'var' foran erklæringen.
Det synes jeg egentlig er ganske simpelt.

MVH Per Thomsen,
http://www.pert.dk/

---

Per Thomsen <pert@pert.dk> writes:

> Lasse Reichstein Nielsen wrote:
> [klip]
>> (en simpel måde at lave lokale variable ville fx være behageligt).
> [klip]
>
> For at lave en lokal variabel, skal man skrive 'var' foran erklæringen.
> Det synes jeg egentlig er ganske simpelt.

Ja, der formulerede jeg mig ikke særlig præcist. Det jeg gerne ville have
var et bagrænset scope for de lokale variable, som fx
for (int i = 0; i<n; i++) {...}
i Java, hvor "i" kun kan ses inde i løkken, eller
(let ((x 42)) ...)
i Scheme eller
let val x = 42 in ...
i ML, som begrænser variablens udstrækning til udtrykket/blokken.

Det er ikke noget der ikke kan simuleres med funktioner, men det
går ud over læsbarheden at skrive
(function (x) { ... })(42)

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

Ok, kan du give et ex på rigtig oop javascript?