[JS] Object-instance met methods

[r0bert]

Ik probeer vanaf de declaratie een Object-instance te maken, die direct toegewezen methods heeft. Ik heb hiervoor redelijk wat search results doorgekeken voor de juiste syntax, aangezien het alweer tijden terug is dat ik zelf geJSt heb.

Nu heb ik deze structuur opgepakt:

JavaScript:

document.server =
{   
    communicate : function()    
    {
    }
    

    connections : function()
    {   
            add : function()
            {   
                try 
                {
              if (window.XMLHttpRequest) 
              {
                    }
                }
                catch (ex)
                {                   
                }
            }
    }
}

Dit heeft de voorkeur voor mij t.o.v. prototyping, aangezien ik dit wat overzichtelijker vind werken. Helaas werkt het script niet. In FF krijg ik de foutmelding:

Fout: missing } after property list
Bronbestand: /js.js
Regel: 8, Kolom: 1
Broncode:
connections : function()

En in IE6

Regel: 9
Teken: 1
Fout: 'document.server' is leeg of geen object
Code: 0
Url: ....

Ook ipv

JavaScript:

document.server =

het gebruik van

JavaScript:

var server =

Lost het probleem niet op.

Waar ga ik de fout in? Het is mij een raadsel.

[r0bert]

Wat een grap. Nog een 5 seconde na dit topic zet ik een ',' (komma) achter de eerste functie en lijkt de foutmelding weg te gaan

Edit:
Het werkt nu prima. Moest onderscheid maken tussen de gewone constructor als

JavaScript:

var varName = 
{
}

En

JavaScript:

var varName = function()
{
}

om ze juist als object te kunnen gebruiken.

[ Voor 99% gewijzigd door r0bert op 10-04-2008 20:16 ]

[crisp]

'add' is een label en geen property aangezien je het binnen een functie-body gebruikt en niet in een object-declaratie

[crisp]

Note dat dit helemaal niets met OO of prototyping te maken heeft, in feite doe je niets anders dan 'namespacing' - je functies zijn verder gewone functies en hebben geen speciale context aangezien je geen object instance hebt maar gewoon een object waar je geen meerdere instances van kan maken. Voor een singleton zonder eigen scope is dat wel bruikbaar maar als je meerdere 'server' objecten wilt kunnen instantieren dan moet je het toch echt anders aanpakken...

[ Voor 30% gewijzigd door crisp op 10-04-2008 11:16 ]

[r0bert]

Nee, er is één server object. Vandaar dat dit hier mogelijk is.

JavaScript:

connections : 
    {   
            add : function()
            {   
                try 
                {
              if (window.XMLHttpRequest) 
              {
                
                    }
                }
                catch (ex)
                {                   
                }
            }
    }

Ik wil nu graag een property 'lastResponse' toevoegen, waarin ik gegevens kan wijzigen, bijvoorbeeld vanuit 'add'. Ik dacht in 'connections : { .. }

var lastResponse;
of
this.lastResponse;
of zelfs
var this.lastResponse;

En dan in add() aanroepen dmv this.lastResponse = 'empty'; Maar dit veroorzaakt allemaal een foutmelding

[ Voor 13% gewijzigd door r0bert op 10-04-2008 20:15 ]

[crisp]

JavaScript:

var server =
{
    connections:
    {
        lastResponse: '',
        add: function()
        {
            this.lastResponse = 'foo';
        }
    }
}

alert(server.connections.lastResponse);
server.connections.add();
alert(server.connections.lastResponse);

zoiets?

[Clay]

je mist een komma achter:

JavaScript:

 communicate : function()    
    {
    } , // <-- hier

't is een soort lijstje

edit:
doh, beter lezen

Je moet idd ff goed checken waar je scope zit, dat verschilt namelijk in zo'n boom:

JavaScript:

document.server = {    
    communicate : function() {
        // this == document.server
    },

    connections : {
        add : function() {
            // this == document.server.connections
            try {
                if (window.XMLHttpRequest) {

                }
            } catch (ex) {
            }
        }
    }
}

[ Voor 62% gewijzigd door Clay op 10-04-2008 15:32 ]

[r0bert]

Hij werkt heerlijk met bovenstaande methode! Heel mooi, ben er superblij mee Bedankt!

[ Voor 5% gewijzigd door r0bert op 10-04-2008 16:12 ]

[r0bert]

Ik heb nog een nieuwe vraag:

JavaScript:

XMLRequest = function()
{   return this.__construct();
}

XMLRequest.prototype = 
{   link : null,
    
    __construct : function()
    {   if (window.XMLHttpRequest)
        {   this.link = new XMLHttpRequest();
            
            // start native //
        if (this.link.readyState == null) 
            {   this.link.readyState = 1;
                this.link.addEventListener("load", function () 
                {   this.link.readyState = 4;
                    if (typeof this.link.onreadystatechange == "function")
                        this.link.onreadystatechange();
                }, false);
            } // end native //
        }
        else
            throw new Error("Your browser does not support XmlHttp objects");
        
        return this.link;
    },
    
    __handle : function()
    {   alert('handling');
    }   
}

Hoe kan ik nou vanuit de onreadystatechange van XMLRequest.link het 'parent' object aanroepen? Ik mag geen properties toevoegen aan .link, dus een reference naar this krijg ik niet voor elkaar.

Ik heb ook al veel alternatieven geprobeerd met Object.prototype.extends en Object.prototype = XMLHttpRequest; om gelijksoortige oplossing te construeren. Tot nu toe is geen enkele gelukt. Ik wil graag een algemene method gebruiken om de request af te handelen.

[_Thanatos_]

En vergeet de puntkomma niet:

JavaScript:

document.server = {
  ...
}; // <-- hier

Het is tenslotte een doodnormaal statement, alleen dan uitgesmeerd over heel veel regels
Het lijkt mierenneuken, maar ten eerste is het gewoon correctheid van je code, en ten tweede zijn puntkomma's na ieder formeel statement verplicht als je je script uiteindelijk gaat packen of minifien.

_{Waarom werkt syntax highlighting niet op mijn codeblokje??}

[ Voor 42% gewijzigd door _Thanatos_ op 11-04-2008 02:09 ]

[crisp]

puntkomma's zijn optioneel hoor (en minifiers die daar geen rekening mee houden zijn flawed by design)

morgen meer repliek, XHR en scope is een cross-browser nightmare - gebruik liever gewoon bestaande libraries dan zelf iets te verzinnen...

[ Voor 16% gewijzigd door crisp op 11-04-2008 02:11 ]

[r0bert]

Dit is maar een relatief klein deel in het script. Vandaar dat ik liever geen hele library gebruik, aangezien dat een beetje overdone wordt. De noodoplossing is dat ik voor iedere nieuwe instance die ik van het object maak, handmatig een onreadystatechange aanroep waarin ik dan een functie aanroep met this als arg, welk de handle doet. Maar da's niet zo mooi natuurlijk, een reference naar this vanuit XHR zou veel mooier zijn naar mijn idee.

[crisp]

Je zal dat toch zelf moeten fixen met wat scoping-magic: http://crisp.tweakblogs.n...-the-scope-of-events.html

[r0bert]

Mm, dat wordt wel erg veel gedoe. Denk dat ik dan i.p.v. 'async', maar 'sync' ga gebruiken en dan na afhandelen het object aanroepen met 'nextHandle' die de wachtrij verder afwerkt. Minder mooi, maar volgens mij een stuk veiliger en lichter. Eventueel met een functie om commando's in de wachtrij te mergen tot 1 set. Scheelt weer wat verbindingen. Advies/ervaring hierover is welkom.

Verduidelijkend stukje trouwens Crisp. Misschien een link naar een voorbeeld van een oplossing toevoegen?

Interessant?
http://www.ilinsky.com/articles/XMLHttpRequest/
http://code.google.com/p/xmlhttprequest/

[ Voor 9% gewijzigd door r0bert op 11-04-2008 17:58 ]

[_Thanatos_]

crisp schreef op vrijdag 11 april 2008 @ 02:10:
puntkomma's zijn optioneel hoor (en minifiers die daar geen rekening mee houden zijn flawed by design)

Nee, puntkomma's zijn verplicht, alleen js-parsers zijn puntkomma-tolerant waardoor het ook werkt als je ze weglaat. Een fiets werkt zonder fietsbel bijv ook, maar toch is ie verplicht

[crisp]

_Thanatos_ schreef op zaterdag 12 april 2008 @ 00:18:
[...]


Nee, puntkomma's zijn verplicht, alleen js-parsers zijn puntkomma-tolerant waardoor het ook werkt als je ze weglaat. Een fiets werkt zonder fietsbel bijv ook, maar toch is ie verplicht

Automatic semicolon insertion is gewoon een beschreven feature van ECMAScript... (7.9)

[ Voor 10% gewijzigd door crisp op 12-04-2008 11:33 ]

[Clay]

en dan kunnen er hele vage dingen gebeuren ala:

JavaScript:

function lorem() {
    return 
        "ipsum";
}

alert(lorem()); // geen ipsum

@r0bert
Async is toch echt wel de mooiere manier, ook al is die misschien wat complexer. Je wil toch bv niet dat een sync request de hele page op slot gooit, en - erger - de user bv net een timeout op die request krijgt.

[r0bert]

Ik snap het punt, Clay, qua snelheid in ieder geval. Ik zit alleen te twijfelen of async niet gevaarlijk wordt aangezien sommige acties (via xhr verstuurt) ook bestanden wijzigen. Dat houdt in dat er twee xhr-edits verstuurt kunnen worden op één bestand. Het is dan wel zaak dat deze op volgorde afgehandelt worden, om incorrecte modificaties die elkaar overlappen te voorkomen. Om dat af te vangen zou ik bij het verzenden een timestamp mee moeten geven. Maar wil ik weten of daar nog een 'vertraagde' xhr op mee komt, dan zal ik een bepaalde periode moeten wachten met het uitvoeren van de volgende edit-commando's. Hetgeen wat uiteindelijk resulteert in een langzamere werking dan sync.

Mogelijk is de beste oplossing om een mengeling toe te passen. Handmatig clientside wijzigingen op dezelfde documenten in een wachtrij bouwen, andere documenten direct doorlaten?

[crisp]

Clay schreef op zaterdag 12 april 2008 @ 16:25:
en dan kunnen er hele vage dingen gebeuren ala:

JavaScript:

function lorem() {
    return 
        "ipsum";
}

alert(lorem()); // geen ipsum

True, maar we hadden het specifiek over minification van javascript die 'stuk' loopt op weggelaten expliciete semicolons. Een goede minifier volgt gewoon de parsing rules van javascript en zal dus of een expliciete semicolon moeten invoegen of de newline achter het statement niet weg moeten halen...

@r0bert
Async is toch echt wel de mooiere manier, ook al is die misschien wat complexer. Je wil toch bv niet dat een sync request de hele page op slot gooit, en - erger - de user bv net een timeout op die request krijgt.

Onze Ajax implementatie 'queued' async requests zodat er maar 1 per keer wordt afgehandeld en ook op de juiste volgorde. Voor een uitgekleed voorbeeld zie ajax.js en de bijbehorende general.js

Overigens is het 'locken' van de browser bij sync requests een implementatie issue. Firefox heeft dat probleem ook al in versie 3 opgelost.

[r0bert]

Onze Ajax implementatie 'queued' async requests zodat er maar 1 per keer wordt afgehandeld en ook op de juiste volgorde. [..]

Behalve als ik een 20x grotere wijziging verstuur direct gevolg door een enkele wijziging?

[crisp]

r0bert schreef op zaterdag 12 april 2008 @ 23:54:
[...]

Behalve als ik een 20x grotere wijziging verstuur direct gevolg door een enkele wijziging?

Hoe bedoel je? Het is FIFO dus als je eerst een grote wijziging verstuurd gevolgt door een kleine dan zal de request voor de kleine wijziging pas verzonden worden als de respons van de grote verwerkt is.

[Civil]

crisp schreef op zondag 13 april 2008 @ 00:02:
[...]

Hoe bedoel je? Het is FIFO dus als je eerst een grote wijziging verstuurd gevolgt door een kleine dan zal de request voor de kleine wijziging pas verzonden worden als de respons van de grote verwerkt is.

Wel als er maar één client is die wijzigingen aanbrengt. Maar als er meerdere clients zijn die wijzingen doorvoeren aan hetzelfde bestand dan is dat niet meer het geval. Nu is het volgens mij zo dat als je bestanden gaat wijzigen op een server je sowieso rekening moet gaan houden met meerdere clients die wijzingen kunnen doorvoeren. Dat gaat buiten de queue van één client om, je bewerkt een bestand dus mogen anderen niet wijzigen op dat moment (je moet gaan locken zodra je het bestand opent).

[crisp]

Civil schreef op zondag 13 april 2008 @ 13:44:
[...]

Wel als er maar één client is die wijzigingen aanbrengt. Maar als er meerdere clients zijn die wijzingen doorvoeren aan hetzelfde bestand dan is dat niet meer het geval. Nu is het volgens mij zo dat als je bestanden gaat wijzigen op een server je sowieso rekening moet gaan houden met meerdere clients die wijzingen kunnen doorvoeren. Dat gaat buiten de queue van één client om, je bewerkt een bestand dus mogen anderen niet wijzigen op dat moment (je moet gaan locken zodra je het bestand opent).

Het is al lastig om met HTTP state te behouden met 1 client, met meerdere clients is dat gewoonweg onmogelijk. Mogelijke oplossingen daarvoor zal je dus serverside moeten implementeren in de vorm van locking en commitment control en duidelijke feedback naar de client.

Zelfs dan is het praktisch onmogelijk om te bepalen op welke 'view' een client een wijziging heeft gemaakt tenzij je bijhoudt wanneer een client precies de informatie opvroeg zodat je serverside kan checken of deze tussentijds gewijzigd is. Dat soort zaken liggen echter compleet buiten de clientside technologie en HTTP.

[ Voor 15% gewijzigd door crisp op 13-04-2008 13:51 ]

[r0bert]

crisp schreef op zondag 13 april 2008 @ 00:02:
[...]

Hoe bedoel je? Het is FIFO dus als je eerst een grote wijziging verstuurd gevolgt door een kleine dan zal de request voor de kleine wijziging pas verzonden worden als de respons van de grote verwerkt is.

Weet je zeker dat dat opgaat? Als die 20x grotere changerequest ook 20x langer duurt om te verzenden (laten we zeggen 20 sec). Na 2 sec. wordt de kleine changerequest verstuurd (duurt 1 sec). Mijn verstand zou zeggen dat ze dan dus niet automatisch op volgorde van versturen verwerkt worden. Maar wat is mijn denkfout?

@Civil:
Ik denk inderdaad dat ik er een sessie-file/object restrictie op moet toepassen. Had ik nog niet echt rekening mee gehouden (Y).

Serverside zou ik ook de wijzigingen in de vorm van een log op kunnen slaan en mocht er nog een changerequest binnen komen die eerder verzonden is, een rollback uit te voeren en met tussenvoeging van de nieuwe changerequest alsnog alles uit te voeren. Maar dit is een overhead die natuurlijk met een beperking als filelocking ook te voorkomen is. Moeilijk afweging.

[crisp]

r0bert schreef op zondag 13 april 2008 @ 18:17:
[...]

Weet je zeker dat dat opgaat? Als die 20x grotere changerequest ook 20x langer duurt om te verzenden (laten we zeggen 20 sec). Na 2 sec. wordt de kleine changerequest verstuurd (duurt 1 sec). Mijn verstand zou zeggen dat ze dan dus niet automatisch op volgorde van versturen verwerkt worden. Maar wat is mijn denkfout?

Ik had het daar puur over requests vanuit 1 enkele client. Als ik vlak achter elkaar namelijk 2 asynchrone requests afvuur vanuit 1 client dan is er geen enkele garantie dat het eerste request ook als eerste de server bereikt.