Den feature jeg savner allermest i JavaScript
Hold model og visning adskilt
Når jeg koder JavaScript, er det som regel på en forholdsvis tyk klient, kodet i ren JavaScript. Jeg forsøger at holde en skarp adskillelse mellem min model og min visning (HTML). For at holde den skarpe adskillelse gør jeg som regel det, at jeg lader min visning lytte på ændringer i modellen og automatisk opdatere visningen, eller HTML?en, så den afspejler ændringen i modellen.
Events på ændringer
Til at understøtte denne metode, som er en afart af Model-View-Controller (MVC) pattern?et, ville det være rigtigt smukt hvis de indbyggede JavaScript objekter understøttede, at man kunne lytte på ændringer. Altså registrerer sig som lytter og få fyret en event, når der skete ændringer. Hvis der for eksempel er en boolean i min model som jeg repræsenterer som en checkboks i min visning, vil jeg meget gerne kunne databinde booleane?en i modellen og checkboksen. Så hvis brugeren ændrer checkboksen bliver min model-boolean også ændret og ikke mindst også omvendt. Så en ændring i min model-boolean bevirker at min checkboks ændrer om den er checked eller ej.
Set før
I bund og grund er det en model set 1000 gange før i andre frameworks jeg efterlyser. Hvis bare vi kunne lytte på ændringer i de indbyggede JavaScript objekter, som fx Array og Object. Ville vi kunne bygge de lækreste databundne JavaScript komponenter. Som det er nu, bliver man nød til at bokse sin model. Dvs. du kan ikke nøjes med at databinde direkte til en reference til en boolean, du bliver nød til enten, at lave en metode der skal kaldes for at opdatere din model, eller at pakke din boolean ind som et objekt, der har setValue og getValue metoder. Det sidste er en teknik jeg har brugt med succes, men det virker lidt klodset. Hvorfor kan man ikke lytte på ændringer af de indbyggede objekter direkte? Min påstand er at det er præcist det enhver GUI-bygger har brug for. Hvad siger du' Har du savnet at kunne lytte på ændringer af de indbyggede objekter'
Om Allan EbdrupKommentarer (38)
Problemet er at det ikke er objekterne der ændre sig, men derimod referencerne. Hvis a ændre sig fra 4 til 5, så hjælper det ikke at lytte på objektet 4.
-
0 -
0
Det kan du have ret i, det kræver du har en variabel du kan referere. Det jeg taler om er noget i denne stil:
[code=javascript]
var a = 5;
function aChanged(objEvent){
//... gør noget
}
a.addChangeHandler(aChanged);
a = 7; //denne tildeling gør at aChanged bliver kaldt
[/code]
Det er addChangeHandler metoden jeg gerne så indbygget i JavaScript.
-
0
-
0
Dit eksempel ville jeg skrive således:
[code=javascript]a=5
function changea(newvalue){
//... gør noget
a=newvalue
}
changea(7)[/code]
Jeg kan ikke se noget særligt behov for den tilføjelse. Den kan måske være svagt brugbar engang imellem, til gengæld kan brugen gøre koden meget sværere at læse da funktionskald vil blive skjult, så samlet set, hvis funktionen var implementeret ville jeg fraråde at bruge den.
Det er ny funktionalitet der topper min ønskeliste. Jeg vil meget gerne have bedre filhåndtering på klientsiden, der er filindlæsning i HTML 5, og det virker fint nok i nogle af de nyeste beta browsere, til gengæld har jeg ikke kunnet finde en tilsvarende gemmefunktion, data URLer giver principielt denne funktionalitet, men mangler filnavne, og er vist ikke rigtigt beregnet til at optræde i a flag.
-
0
-
0
Hvis følgende kode skal give mening skal sproget tilbyde operator-overloading, og det er jeg ikke sikker på at jeg ønsker mig i JavaScript.
a.addChangeHandler(aChanged);
a = 7;
-
0
-
0
@JACOB CHRISTIAN MUNCH-ANDERSEN
På den måde du foreslår for du blandet din model sammen med din visning. Det er for at få en ren adskillelse af model og visning jeg foreslår det.
Hvis JavaScript understøttede dette er min påstand at de JavaScript Widgets/komponenter vi ville have ville være af meget højere kvalitet, fordi det ville ligge lige til højrebenet at lave en god adskillelse af tingene. Jeg mener faktisk at det samme gør sig gældende for WinForms applikationer. Ovenstående feature et præcist hvad en god GUI-bygger har brug for.
Men du adskiller måske ikke model og visning? Eller ser måske ikke behovet?
-
0
-
0
@KIM DALSGAARD
Nej jeg foreslår ikke operator overloading, blod denne ene feature med at kunne få fyret events når et objekt ændrer sig, uden at skulle lave klodsede løsninger.
JavaScript frameworket SproutCore har en løsning som du kan læse mere om har:
http://wiki.sproutcore.com/PropertyObserving-About?SearchFor=bindings&sp=4
Men det er i min mening en klodset måde at gøre tingene på. Men det virker og er ekstremt kraftfuldt når du bygger en GUI.
-
0
-
0
På Mac har de det også, de kalder det Key-Value observing (jeg har aldrig prøvet det)
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Ke...
Som Jeff Watkins skriver her:
http://nerd.metrocat.org/2005/08/key-value-coding-and-observing
This technology is built into Apple’s Objective-C runtime and forms the foundation of the greatest advancement in UI programming: Cocoa Bindings.
Han viser også hvordan man kan gøre noget tilsvarende i JavaScript i ovenstående link. Men det er en lidt klundet måde at gøre tingene på. Det burde være indbygget direkte i JavaScript, når nu JavaScript er GUI-bygger sprog nummer et.
-
0
-
0
Jeg forstår ikke hvorledes model og visning er adskilt i din kode men ikke i min.
Din kommentar om at dit forslag skulle medføre meget højere kvalitet har jeg svært ved at tage seriøst. Kvalitet hænger først og fremmest sammen med programmørens evner, programmeringssproget spiller også en rolle, men den er meget mindre, så at en enkelt lille tilføjelse til sproget skulle have nogen mærkbar effekt på den samlede kvalitet, det forekommer usandsynligt.
-
0
-
0
Huh? At tillade implementering af en Observer er da netop ideelt.
Hvis der er noget som mangler, så er det da programmører som forstå event baseret programmering...
Og Javascript har jo også allerede events indbygget i sproget, som f.eks. onLoad events på DOM visse elementer. Det er kun et spørgsmål om at videreudvikle sproget til at tillade nemmere implementering af observer nemmere end det er i dag.
Problemet er dog, at de fleste sprog hvor man implementere observer i, f.eks. PHP, C++, C# eller Java, skal man under alle omstændigheder ud i en form for properties, istedet for public fields.
Hvis man nu engang vil have sådanne OO features, burde man jo netop tillade access modifiers (PPP) i Javascript, og have en rigtig skildring mellem fields og properties.
Javascript, elegang som det er, tillader jo ret nem implementering af closures (delegates for jer som kan C#), hvilket burde gøre det relativt simpelt at implementere en form for observer.
Dog synes jeg ikke det hører til på value-types, som f.eks. en integer.
-
0
-
0
Derudover synes jeg ikke det er så vanvittig besværlig at implementere manuel observer, det kræver stadigvæk mindre kode end f.eks. Java:
Eksempel med flere attached listeners: http://clausjoergensen.dk/media/files/door.html
Umiddelbart ville en løsning ala. INotifyPropertyChanged(1) være en bedre løsning, men nu er interfaces jo ikke Javascript's stærke side. Og det er vel også på grænset af hvad man forventer af et "script" sprog, som skal være hurtigt og flexibelt, istedet for at have alle de features et fuldt sprog har.
(1) http://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypro...
-
0
-
0
Jeg forstår ikke hvorledes model og visning er adskilt i din kode men ikke i min.
Ja jeg skulle nok have forklaret lidt grundigere.
Hvis a i eksemplet er din model og aChanged er din binding til din visning, så skal du kunne kode op mod a og ændre a's værdi fuldstændigt uden at tage hensyn til at der er noget der hedder aChanged. Hvis man gør som du foreslår får man de to ting blandet sammen.
Din kommentar om at dit forslag skulle medføre meget højere kvalitet har jeg svært ved at tage seriøst. Kvalitet hænger først og fremmest sammen med programmørens evner, programmeringssproget spiller også en rolle, men den er meget mindre, så at en enkelt lille tilføjelse til sproget skulle have nogen mærkbar effekt på den samlede kvalitet, det forekommer usandsynligt.
Så du mener heller ikke at fx tilføjelsen af generics i dotNet og Java giver pænere strukturerede programmer. Eller at objektorientering giver pænere programmer. Eller at der findes noget andet programmeringssprog end assembler. Eller du koder måske bitstrømmen direkte med 0'er og 1'er?
Jeg er ikke et sekund i tvivl om at det jeg foreslår ville forbedre javascript widgets og frameworks.
At du er uenig er fair nok, men at sige at en feature i et programmeringssprog umuligt kan have betydning for kvaliteten af de programmer der laves med det og så med den formulering du gør det, jah hvad skal jeg sige?
Du har dog ret i at kvaliteten også hænger sammen med programmørenes evner, men de folk der bygger widgets osv er skam meget dygtige.
-
0
-
0
Derudover synes jeg ikke det er så vanvittig besværlig at implementere manuel observer, det kræver stadigvæk mindre kode end f.eks. Java: Eksempel med flere attached listeners: http://clausjoergensen.dk/media/fil...
Det er ikke kun et spørgsmål om hvor svært det er, det er også et spørgsmål om hvor rene linier der er mellem model og visning. I dit eksempel kalder toggle funktionen de events der gerne vil lytte, toggel er en del af din model som jeg ser det. Det jeg gerne vil have er at du kan lave din model fuldstændigt uden at skulle tage hensyn til at der er nogen de lytter på den. Derudover synes jeg ikke dit eksempel er meget simpelt, jeg vil gerne have gjort det meget mere simpelt.
Umiddelbart ville en løsning ala. INotifyPropertyChanged(1) være en bedre
Jeg synes ikke INotifyPropertyChanged som du linker til ser særligt elegant ud, og hårene rejser sig på mig når jeg ser at propertiens navn sendes som en tekststreng.
Det optimale ville være hvis alle browsere oveni understøttede defineGetter og defineSetter som beskrevet her:
http://ejohn.org/blog/javascript-getters-and-setters/
-
0
-
0
Idéen ligger meget tæt op af Bindings i ActionScript/Flex.
Subject:
[code=ActionScript]
class MySubject extends EventDispatcher{
[Bindable]
public var a:String;
}
[/code]
[code=ActionScript]
class MyObserver{
private var myS:MySubject = new MySubject();
private var mySWatcher:ChangeWatcher;
public function MyObserver():void{
mySWatcher = BindingUtils.bindSetter(setterFunc, myS,'a');
}
public function setterFunc(value:String):void{
// Gør et eller andet.
}
}
[/code]
I Flex er selve bindingen lidt nemmere, der skal modtageren bare være en property, og så bruger man {} til at binde:
<myPackage:MyFlexObserver test="{myS.a}" />
ActionScript er bestemt ikke perfekt, og jeg har et mindre had til store dele af Flex Frameworket, men IMHO er det den eneste implementering af ECMAScript der ikke stinker.
-
0
-
0
Jeg kom lige i tanke om et blogindlæg fra John Resig jeg engang har læst, http://ejohn.org/blog/javascript-getters-and-setters/.
Desværre virker det ikke i alle browsere, men sådan vil det jo nok altid være når det er en ny feature i selve sproget...
-
0
-
0
Nu bliver jeg sku sur, du lægger ord i munden på mig, jeg siger ikke at en ny feature er uden betydning for kvaliteten, men at en lille feature som fx omtalte har meget lille betydning.
Hvis ikke du kan finde ud af at argumentere ordentligt så kan du have din blog for dig selv.
-
0
-
0
@JACOB CHRISTIAN MUNCH-ANDERSEN
Ja undskyld, det var ikke for at skræme dig væk. Du skriver jo selv du ikke kan tage det seriøst. Det jeg prøver at illustrere er at jeg mene denne feature, lavet godt, ville være lige så vigtig en feature som generics for dotNet og Java. Det var ikke for at ligge ord i munden på dig. Jeg tager gerne en diskussion om hvorfor. Hvorfor synes du ikke det batter?
-
0
-
0
I dit eksempel kalder toggle funktionen de events der gerne vil lytte, toggel er en del af din model som jeg ser det. Det jeg gerne vil have er at du kan lave din model fuldstændigt uden at skulle tage hensyn til at der er nogen de lytter på den.
Det er jo så spørgsmålet! Fordi hvilket sprog tillader faktisk sådan en feature?
Den generelle model for implemetering af observer, er jo netop ved at man manuelt notifier sine observers.
Alt andet ville jo kræve et hav af reflection. Jeg kunne godt tænke den tanke at det måske slet ikke er muligt, uden alt for stort performance tab.
Fordi Hejlsberg er en klog man, og man ville tænke at dette er et punk som han ville havde overvejet.
Måske skulle man sende ham en mail og spørge.
Derudover synes jeg ikke dit eksempel er meget simpelt, jeg vil gerne have gjort det meget mere simpelt.
Jeg skrev det med intention i stil med C++/Java/C# :)
-
0
-
0
Hvorfor sidder en Enterprise Architect og koder Javascript?
Fordi han ikke kan lade være i sin fritid. Det er ikke i forbindelse med mit arbejde. Nu du siger det så synes jeg at jeg har oplevet at mange it-arkitekter ikke bekymrer sig om arkitekturen i GUI'en. Den synes jeg også er umådelig interresant og den bør man ikke overse.
-
0
-
0
Ok, jeg overreagerede måske lidt.
Anyway, hvis vi kigger på generics så er det så vidt jeg kan forstå en metode til at sikre en compiler fejl hvis man forsøger at placere et objekt af en forkert type i en liste (korriger mig hvis jeg har misset noget af betydning). Fin nok brugbar feature, men man kan skrive præcis den samme kode uden, og rent personligt husker jeg ikke nogensinde at have haft store kvaler med det problem som generics løser, så jeg kan ikke tro at generics skulle have nogen mærkbar effekt på kvaliteten af min kode.
Ligeledes savner jeg ikke listeners på variable, eneste forskel er at hvor generics giver en lille forbedring af kodens læsbarhed så kan listeners nedsætte den dramatisk.
-
0
-
0
Det er jo så spørgsmålet! Fordi hvilket sprog tillader faktisk sådan en feature?
Ja efter min mening burde alle sprog til at bygge GUI'er understøtte det.
Jeg fandt faktisk en måde at gøre det i C#, men det var et hack og endte med at være ubrugeligt, af den ene grund at debuggeren spassede helt ud når man brugte hacket. Ellers ville det have været smukt.
Den generelle model for implemetering af observer, er jo netop ved at man manuelt notifier sine observers.
Der er mange ting der har ændret sig i programmeringssprog over tiden. Jeg kan ikke se det som et argument for at man ikke skal gøre det.
Alt andet ville jo kræve et hav af reflection. Jeg kunne godt tænke den tanke at det måske slet ikke er muligt, uden alt for stort performance tab.
Muligvis for C#, men jeg køber den ikke for JavaScript. Jeg er sikker på at når de intelligente sprog-byggere fik jobbet, ville de komme på smarte løsninger med god performance.
Fordi Hejlsberg er en klog man, og man ville tænke at dette er et punk som han ville havde overvejet. Måske skulle man sende ham en mail og spørge
Jeg har skam talt med ham in-person. Hans svar var noget i retningen af: "Der er så mange ting vi kunne lave der ville give god mening, men vi kan simpelthen kun nå en brødkdel af det vi gerne ville lave"
Alle laver fejl, fx har han sagt at han gerne ville have haft en feature i C# hvor man specificerede at en variabel ikke kunne være null. Men det er for sent/svært at putte i C# nu. Det kunne jeg godt have fortalt ham at han skulle have haft med ;-)
-
0
-
0
Anyway, hvis vi kigger på generics så er det så vidt jeg kan forstå en metode til at sikre en compiler fejl hvis man forsøger at placere et objekt af en forkert type i en liste (korriger mig hvis jeg har misset noget af betydning). Fin nok brugbar feature, men man kan skrive præcis den samme kode uden, og rent personligt husker jeg ikke nogensinde at have haft store kvaler med det problem som generics løser, så jeg kan ikke tro at generics skulle have nogen mærkbar effekt på kvaliteten af min kode.
Nu var det ikke fordi dette skulle udvikle sig til en diskussion af fortræffentlighederne i generics, og det var ikke for at sammenligne med 1:1 med generics. Jeg tror du bevæger dig på et meget teoretisk plan når du siger at generics ikke har betydning for kvaliteten af kode (du siger godnok kun din kode). Hvis du taler om noget så smukt som generics nærmest som bare syntaktisk sukker, kommer jeg nemt til den konklusion at du bare vil have enhver regnemaskine der er turing-komplet og så er du glad. Men anyway, sammenligningen med generics var for at vise at jeg mener det jeg taler om er lige så vigtigt, og det bider så åbenbart ikke på dig.
Men kan du se at man med ovenstående feature ville kunne adskille sin model fuldstændigt fra sin visning, dvs. Lave sin model uden at tage hensyn til hvordan den skal vises? Og hvis du kan se det, synes du så ikke det er en god idé, at adskille model og visning fuldstændigt?
Ligeledes savner jeg ikke listeners på variable, eneste forskel er at hvor generics giver en lille forbedring af kodens læsbarhed så kan listeners nedsætte den dramatisk.
Som nævnt findes tilsvarende features allerede i Flex og på Mac, jeg har ikke fundet nogen der advarede mod brugen af denne feature fordi den skulle nedsætte læsbarheden af koden.
Jeg har selv lavet et JavaScript framework hvor metode er implementeret, og har ingen problemer med læsbarheden af koden. Det eneste der måske kunne give lidt udfordringer er debugging, callstackken bliver lidt længere, til gengæld bliver det meget tydeligt hvornår du er i modellen og hvornår du er i visningen. Metoden har til gengæld gjort mig i stand til at lave en generisk undo funktionalitet som jeg skrev om i mit første blog indlæg:
http://www.version2.dk/artikel/9808-hvad-blev-der-af-fortryd
Hvis du vil prøve det selv så gå ind på:
http://obsurvey.com
klik "Try now"
klik enter
og rod rundt i editoren, alt kan undo'es og redo'es
-
0
-
0
Det er tit en fordel at designe små sprog, men at gøre udvidelser nemme.
I JavaScript vil det være 'simpelt' at bygge noget ala.
var model = new Model("firstName", "lastName");
model.firstName("Kim");
alert(model.firstName());
model.firstName.notify(function(firstName) { ... });
-
0
-
0
Jeg forstår ikke behovet for en sådan funktion når du har mulighed for at gøre flg:
function setA(value) {
// Skriv din kode her?
a = value;
}
Det eneste behov for en observer er hvis du ikke selv har skrevet lige netop den linje kode som ændrer din variable. Som fx. ved et user genereret event. Og i det tilfælde findes der jo masser af events i JavaScript.
Du snakker om en checkbox? det er vel bare at binde .change til en funktion for pågældende checkbox object? Men det ved du jo nok godt.
-
0
-
0
@Kim Dalsgaard
Du har fuldstændigt ret, jeg har også fundet eksempler på JavaScript frameworks der har implementeret noget i den stil fx SproutCore og Cappuccino (og jeg har selv lavet et).
Det bliver bare så kluntet og svært at bruge, og nu var topic, det jeg savner mest i JavaScript.
-
0
-
0
Jeg forstår ikke behovet for en sådan funktion når du har mulighed for at gøre flg: function setA(value) { // Skriv din kode her? a = value; }
Det hele handler om at have en model der er fuldstændigt adskilt fra din visning af denne model. I det ovenstående vil funktionen setA være en del af din model, mens den kode du har ved
// Skriv din kode her?
er bindingen til din visning.
Overordnet er problemet at din model og din visning hurtigt bliver rodet sammen og det er ikke naturligt og lige for, at have en skarp opdeling. Så faren er at du ender med noget værre rod til sidst.
Noget som du kan fx ikke kan, er at bruge din model eller dele af den til andre formål. Det er faktisk noget man kan bruge i praksis. Tænk fx på et bruger (user) objekt du vil bruge mange steder på dit site.
-
0
-
0
@Allan
Hvor bliver det kluntet? Der er da ikke langt fra
model.firstName = "Kim";
til
model.firstName("Kim");
Jeg synes ikke det er vær at udvide JavaScript for så lidt.
-
0
-
0
Kim, det er ikke kaldet der er kluntet, men det ekstra kode der skal ind i modellen (for hver eneste værdi der skal kunne lyttes på).
Allerhelst burde kun den der skal observe, vælge at lytte efter ændringer, mens subject slet ikke skal have ekstra kode.
-
0
-
0
@Dennis
Det smarte er jo at den ekstra kode tilføjes automatisk i constructor'en
var model = new Model("firstName", "lastName");
Der er fordele ved dynamiske sprog ;-)
-
0
-
0
Der er mange ting der har ændret sig i programmeringssprog over tiden. Jeg kan ikke se det som et argument for at man ikke skal gøre det.
Det er så rigtigt nok. Men alligevel, det er jo ret dratisk at tilføje en liste af observers på hver eneste objekt (som altig så nedarver fra).
En måde ala. hvad Kim Dalsgaard viser, ville nok mere være i retning af en mulig løsning.
-
0
-
0
Men alligevel, det er jo ret dratisk at tilføje en liste af observers på hver eneste objekt (som altig så nedarver fra).
Så længe du bare potentielt kan have en observer er det fint. Jeg forestiller mig at man ville have to sæt klasser, en med observers og en uden, og så først bruge dem med observers, når der var tilføjet observers.
Jeg er ret overbevist om at vi ville se nogle ret fantastiske løsninger hvis JavaScript havde denne feature. Men jeg er da godt klar over, at det nok er ren ønsketænkning. Men måske er der en mulighed i GWT eller Objective-J for at man kunne få noget framework der understøtter det og laver den boilerplate-kode der skal til under the covers.
-
0
-
0
Jeg tror at vi snakker forbi hinanden.
Idéen er,som jeg fanger det, at modellen både skal være simpel (som i rene valueobjects), og automatisk skal kunne sende events/notifications/updates når en værdi bliver opdateret, uden at andet ned det objekt der er interesseret i updates, behøver at gøre noget.
Ikke modellen, og ikke den der laver opdateringen (det sidste er meget værre).
- Præcis som i ActionScript/Flex (udover at værdien eller klassen den sidder på, skal erklæres Bindable).
-
0
-
0
Så prøver jeg igen
var model = bindable({firstName: "Kim", lastName: "Dalsgaard"});
model.firstName.notify(function() {...});
-
0
-
0
udover at værdien eller klassen den sidder på, skal erklæres Bindable
Metaprogrammering er en ret generel måde at løse ting på.
Og ja, det ville nok også passe fint ind i Javascript, jeg synes bare at man skal passe på sprogets performance mht. reflection, da mange sider er ret javascript tunge i dag, og stadigvæk kan crashe en del browsere.
-
0
-
0
@Kim Dalsgaard
Du har ret i at man kan programmere sig ud af det, jeg sidder med sådan en løsning, og som jeg nævner er der flere frameworks der har sådanne løsninger. Min erfraing fra at arbejde med det er bare at det virker omstændigt og kluntet. Jeg synes det er så vigtig en feature at den burde være en elegant løsning direkte i JavaScript.
Derudover vile det også være smukt hvis det var understøttet i dom'en, så du kunne binde direkte til fx .checked på en checkboks. Så kunne du få opdateret din model lige meget om checked blev ændret af en bruge-event eller af et andet stykke kode. Det kunne fx bruges til at lave bedre automatiske tests af din GUI, der ikke kræver at rigtige bruger-events bliver fyret. (Telerik har den slags model til at teste mod deres kontroller)
Og jeg er sikker på at der ville være rigtigt mange andre scenarier hvor teknikken ville kunne bruges til andet fornuftigt hvis man havde den.
-
0
-
0
Et af de fremmeste formål med Model - View - ViewModel patternet er at adskille UI fra domænet. Alt 'slammet' (a.k.a. UI-koden) bliver så isoleret til ViewModel'en. (Jeg koder ikke selv i JavaScript, så der kan være fundementale forskelle som umuliggør det).
-
0
-
0
Læste lige lidt her:
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
Det er det jeg mener at du kunne have hvis du havde ovenstående feature i javascript også i dom'en
Jeg har kodet på et JavaScript framework der arbejder på en måde meget tæt på dette pattern siden 2002.
Du kan læse mere om mit arbejde i to artikler
her:
http://obsurvey.com/SARD.aspx
og her:
http://obsurvey.com/UIA.aspx
Jeg kalder det ikke en viewModel, men en "conceptual display model" (havde først kaldt det en view model men det blev lidt for meget view og model så jeg rettede det :-)
-
0
-
0
Det er ret sjovt, de bruger closures til at binde et objekt og en metode på objektets klasse sammen:
[code=csharp]
RelayCommand _saveCommand;
public ICommand SaveCommand
{
get
{
if (_saveCommand == null)
{
_saveCommand = new RelayCommand(param => this.Save(),
param => this.CanSave );
}
return _saveCommand;
}
}
[/code]
Det er koden
[code=csharp]
param => this.Save()
[/code]
Jeg mener. Det samme gør jeg i JavaScript med denne metode:
[code=javascript]
Uia.thisWrap = function (fnFunction, nvntThis){
if(!Uia.isFunction(fnFunction)) throw new Error("Not a function");
var fnWrappedFunction = function(_this, _f){
return function(){ return _f.apply(_this, Uia.argumentsToArray(arguments)); };
}(nvntThis, fnFunction);
return fnWrappedFunction;
}
[/code]
Jeg har så pakket den ind i mit framework så man nemt kan hive en this wrapped metode ud fra et objekt og sende den videre i til et andet lag.
-
0
-
0
Tilføj kommentar
