[Javascript] Eval functie

[wboard]

Als ik onderstaand in EVAL() prop, (nodig voor AJAX applicatie) werkt het in alle browsers prima, behalve!! NETSCAPE

code:

        window.onbeforeunload = function()
        {
            if(confirm("vraag?"))
            {
                //do            
                                }
            else
            {
                //do
            }       
        }

Ik kan hier niets over vinden, de melding die ik krijg is als volgt: (SyntaxError: missing } in compound statement). Uitleg bij deze melding is niet nodig, dat spreekt voor zich, maar zie jij ergens een missende }???

Toen heb ik voor de grap er dit van gemaakt:

code:

        window.onbeforeunload = function(){if(confirm("vraag?')){   }else{}}

en dan krijg ik (SyntaxError: missing ; before statement)

Iemand een idee?

[ Voor 6% gewijzigd door wboard op 28-01-2007 21:16 ]

[BradJohnson]

if(confirm("vraag?"))

[skabouter]

In je code staat een ' ipv een " bij de confirm

code:

        window.onbeforeunload = function()
        {
            if(confirm("vraag?"))
            {
                //do            
                                }
            else
            {
                //do
            }        
        }

code:

window.onbeforeunload = function(){if(confirm("vraag?")){    }else{}}

[Suaver]

Misschien omdat je in je if statement 'n fout hebt?

JavaScript:

window.onbeforeunload = function() {
  if(confirm("vraag?")) {
     // Doe dingen hier.    
  }
  else {
     // En ook hier.
  }        
}

[Michali]

Is het trouwens niet zo dat je bij onbeforeunload een string moet returnen, die dan gebruikt wordt voor een automatische popup?

[wboard]

niets van bovenstaand zaken werkt, bij confirm() kun je ' of " gebruiken.
en in mijn if statement staat niets om het debuggen te vergemakkelijken.

Let wel, als ik deze javascript gewoon los op mijn pagina uitvoer, doet hij het wel!!

[ Voor 23% gewijzigd door wboard op 28-01-2007 15:48 ]

[Suaver]

Gebruik anders de onderstaande functie, gewoon van internet geplukt.

JavaScript:

window.onbeforeunload = function (evt) {
  var message = 'Are you sure you want to leave?';
  if (typeof evt == 'undefined') {
    evt = window.event;
  }
  if (evt) {
    evt.returnValue = message;
  }
  return message;
}

[wboard]

dat heeft geen effect, de functie zelf werkt opzich wel, alleen wanneer je het in de eval() functie stopt geeft hij die foutmeldingen. En ik moet er een confirm in hebben, omdat aan beide acties nog een functie call hangt!

[ Voor 24% gewijzigd door wboard op 28-01-2007 16:12 ]

[Victor]

wboard schreef op zondag 28 januari 2007 @ 15:47:
niets van bovenstaand zaken werkt, bij confirm() kun je ' of " gebruiken.

Maar je moet niet openen met " en sluiten met '

[wboard]

ow das een tikfout , sorry (was geen copy past van de code), maar dat werkt dus nog steeds niet.
Ik vindt het een heel vreemd verhaal...

[ Voor 66% gewijzigd door wboard op 28-01-2007 21:17 ]

[crisp]

wboard schreef op zondag 28 januari 2007 @ 15:22:
Als ik onderstaand in EVAL() prop, (nodig voor AJAX applicatie) werkt het in alle browsers prima, behalve!! NETSCAPE

Welke Netscape? 4.x? 6.x? 7.x?
Is Netscape-ondersteuning ueberhaupt nog wel belangrijk gezien het feit dat het markt-aandeel van deze browser toch nagenoeg 0 is omdat iedereen tegenwoordig Firefox gebruikt?

[wboard]

Netscape Browser 8.1.2, je hebt daar wel een punt, maar de ondersteuning is eigenlijk rond behalve met dit verhaal.

[giMoz]

andere oplossing: doe het niet met eval(), dat vind ik sowieso altijd al beetje 'enge' functie..

[Michali]

Geef het meest kleine/minimale stukje code eens dat een syntax error oplevert in Netscape. Dan kunnen we snel zien of het aan de code ligt, of dat het een browserbug is.

[wboard]

ik post het vanavond even, zit nu ergens anders
@BtM909, ja sorry ik was iets te snel aan het posten

dit is wat ik exact terug krijg na mijn AJAX request

code:

<div class="returnedJs">
    <script type="text/javascript">
        window.onbeforeunload = function(){
            if(confirm('vraag?'))
            {
            }
            else
            {
                messageToScreen('melding', 'custom');
            }
        }
    </script>
</div>

en met deze functie voer ik de javascripts uit:

code:

    function execJs(node) 
    {
        var st = node.getElementsByTagName('SCRIPT');
        var strExec;
        for(var i=0;i<st.length; i++) 
        {     
            if (bSaf) 
            {
                strExec = st[i].innerHTML;
            }
            else if (bOpera) 
            {
                strExec = st[i].text;
            }
            else if (bMoz) 
            {
                strExec = st[i].textContent;
            }
            else 
            {
                strExec = st[i].text;
            }
            try 
            {
                eval(strExec);
            } 
            catch(e) 
            {
                alert(e);
            }
        }
    }

maar als het dus BETER kan ZONDER eval, ben ik daar wel naar geïnteresseerd

[ Voor 91% gewijzigd door wboard op 29-01-2007 20:07 ]

[wboard]

giMoz schreef op maandag 29 januari 2007 @ 09:42:
andere oplossing: doe het niet met eval(), dat vind ik sowieso altijd al beetje 'enge' functie..

wat is de oplossing dan? welke andere functie biedt die mogelijkheden?

[BtM909]

Als je als laatste reageert, gebruik dan even de knop

[wboard]

kick, check mijn gewijzigde reply (dat bedoel ik dus, nietmand leest de gewijzigde )

[BtM909]

wboard schreef op dinsdag 30 januari 2007 @ 16:23:
kick, check mijn gewijzigde reply (dat bedoel ik dus, nietmand leest de gewijzigde )

Daarom zei ik ook, als je als laatste reageert (in een topic). Anders je minimaal 24 uur wachten voordat je je eigen topic kan kicken

[ Voor 6% gewijzigd door BtM909 op 30-01-2007 17:03 ]

[wboard]

29-01-2007 20:07, ik zat er maar 2 uur naast. Maar dan nu een legale kick

[giMoz]

je genereerd nu javascript server side, dat geef je vervolgens terug om dat uit te voeren......
Laat je server geen javascript genereren, dan hoef je ook niet te evallen.

Bij ajax zoals ajax ooit bedoelt is geeft de server XML terug met daarin data, en de javascript beslist dan op basis van die data wat ie moet doen (bijv een confirmbox tonen....)

[crisp]

giMoz schreef op donderdag 01 februari 2007 @ 09:00:
je genereerd nu javascript server side, dat geef je vervolgens terug om dat uit te voeren......
Laat je server geen javascript genereren, dan hoef je ook niet te evallen.

Bij ajax zoals ajax ooit bedoelt is geeft de server XML terug met daarin data, en de javascript beslist dan op basis van die data wat ie moet doen (bijv een confirmbox tonen....)

Hoewel ik het ermee eens ben dat je beter puur data kan versturen en de logica bij de applicatie zelf moet houden (op basis van die data) ben ik het er niet mee eens dat die data per-sé in XML-formaat zou moeten zijn. Ajax is gewoon een (slechtgekozen) verzamelnaam voor een aantal technieken die eigenlijk niet echt een direct verband met XML hebben. Zelfs de 'Xml' in XmlHTTPRequest is destijds enkel aan de naam toegevoegd omdat het toen 'hot' was.
Tegenwoordig maakt vooral het light-weight JSON formaat een behoorlijk opmars binnen eenvoudige Ajax-applicaties

[Michali]

Idd. Ik maak daarbij dan niets eens gebruik van third party libs. Ik output met PHP objecten in javascript object formaat, die ik dan aan de clientside weer eval naar een javscript object. De hele overhead van XML is er dan niet. Het werkt voor veel zaken gewoon een stuk sneller.

[Verwijderd]

ik ben geen expert als het op javascript aankomt maar in PHP bijvoorbeeld moet je erg opletten met de quoutes omdat anders het einde van de eval wordt gemist. mischien dat netscape hier iets stricter in is en je dus dwight omde quoutes te escapen.

verder is eval in elke taal iets om te vermijden volgensmij. en het zou niet de eerste keer zijn dat netscape de regels net iets meer to-the-point volgt dan de andere browsers. vooral IE&Firefox schijnen nogal slordig om te gaan met javascript terwijl netscape practische javascript heeft bedacht.

[Michali]

Klopt. Verder moet je ook \n en \r (en volgens mij ook \t) escapen, omdat een javascript string niet op 2 regels mag staan. Je moet er dan ipv. whitespace characters een slash met de letter van maken. Bij het evallen in javascript wordt er dan weer een whitespace van gemaakt zoals hij was.

[crisp]

Verwijderd schreef op donderdag 01 februari 2007 @ 09:59:
verder is eval in elke taal iets om te vermijden volgensmij. en het zou niet de eerste keer zijn dat netscape de regels net iets meer to-the-point volgt dan de andere browsers. vooral IE&Firefox schijnen nogal slordig om te gaan met javascript terwijl netscape practische javascript heeft bedacht.

euh, Mozilla's script-engine is een doorontwikkeling van de oude Netscape javascript engine. Netscape is vanaf versie 6 gewoon Mozilla met een eigen interface. Netscape bouwt al jaren geen eigen browsers meer...

[Verwijderd]

maar netscape gebruikt nog wel steeds haar eigen tweaks enzo, anders zouden netscape en firefox gelijk presteren wat ook niet waar is, hoewel ze beide op de Gecko engine gebaseerd zijn, zijn er toch echt wel verschillen in hoe ze ook met javascript omgaan.

[crisp]

Verwijderd schreef op donderdag 01 februari 2007 @ 11:16:
maar netscape gebruikt nog wel steeds haar eigen tweaks enzo, anders zouden netscape en firefox gelijk presteren wat ook niet waar is, hoewel ze beide op de Gecko engine gebaseerd zijn, zijn er toch echt wel verschillen in hoe ze ook met javascript omgaan.

Verschillen als in: Netscape is buggier dan Firefox ja

[BtM909]

Geef eens een real life voorbeeld dan?

[wboard]

giMoz schreef op donderdag 01 februari 2007 @ 09:00:
je genereerd nu javascript server side, dat geef je vervolgens terug om dat uit te voeren......
Laat je server geen javascript genereren, dan hoef je ook niet te evallen.

Bij ajax zoals ajax ooit bedoelt is geeft de server XML terug met daarin data, en de javascript beslist dan op basis van die data wat ie moet doen (bijv een confirmbox tonen....)

dat klinkt leuk, maar praktisch gezien is dat niet echt efficiënt werken, zeker wanneer je veel verschillend javascript outputs in je applicatie hebt.

[crisp]

wboard schreef op donderdag 01 februari 2007 @ 22:40:
[...]


dat klinkt leuk, maar praktisch gezien is dat niet echt efficiënt werken, zeker wanneer je veel verschillend javascript outputs in je applicatie hebt.

logica in je data stoppen is juist niet erg praktisch; scheiding tussen data en business logic is gewoon good practice...

[wboard]

maar in mijn geval denk ik dat dat een stuk lastiger uit te voeren is..

[wboard]

crisp schreef op donderdag 01 februari 2007 @ 22:57:
[...]

logica in je data stoppen is juist niet erg praktisch; scheiding tussen data en business logic is gewoon good practice...

beetje een late reactie hierop, maar ik loop vaak te tobben met zulke concepts. Hoe krijg je die scheiding nu concreet voor elkaar (afgaand van wat ik nodig heb voor mijn web applicatie?)

Uiteindelijk heb je natuurlijk je:
- data
- layout
- je clientside acties op data die de browser voorgeschoteld krijgt uit de database

ik hoor het wel

[Michali]

Eigenlijk is het vrij simpel. Je hebt een bepaalde trigger (een event) die er voor zorgt dat je je scherm wilt gaan updaten. Hiervoor heb je in sommige gevallen nieuwe of verse gegevens vanaf de server nodig. Hiervoor doe je dan een request naar de server voor die specifieke gegevens. Wat je dan ophaalt is enkel en alleen de informatie die je nodig hebt voor de betreffende handeling. Je haalt geen presentatie code op en ook zeker geen logica.

Op basis van de gegevens die je dan hebt opgehaald kun je dan bewerkingen in je document gaan doen. Dat is dus je logica die al klaar moet staan, alle logica die je mogelijk nodig gaat hebben binnen de betreffende pagina moet dus al klaar staan. Hierna haal je alleen gegevens op die je dan gebruikt voor een handeling of een weergave.

Je zegt dat het niet efficiënt werkt, maar uit eigen ervaring kan ik je toch wel melden dat het zeker wel efficiënt werkt als je het goed in elkaar zet. Ook kan ik je melden dat jouw methode je echt de kop op gaat breken als je applicatie wat groter wordt en je op verschillende plaatsen wat wijzigingen moet gaan doorvoeren. Gestructureerd werken bespaart je in zo'n geval veel problemen en dus veel tijd.

Geef eens een concreet voorbeeld van wat je zou willen doen? Dan kan ik je enkele stappen laten zien om dit netjes voor elkaar te krijgen.

[wboard]

bedankt voor je reactie! een voorbeeld van een actie die ik wil doen:

1) een document staat open en deze wil ik OPSLAAN ALS
2) m.b.v. javascript zorg ik er voor dat het formulier met veel velden (het document dus) uitgelezen wordt en gepost wordt naar de server. De server slaat het vervolgens op in de database (als zijnde een nieuw id, simpel gezegd).
3) het script moet vervolgens returnen dat het document succesvol is opgeslagen als .... (dit in javascript messageBox) en moet vervolgens het nieuwe document laden binnen een bepaalde div...
4) omdat diversen andere divs als gevolg van het wijzigen van het document ook nieuwe data moeten ophalen, stuur ik dus javascript mee die er voor zorgt dat de nieuwe divs ook nieuwe data op gaan halen


een ander voorbeeld:
1) een document staat open (een soort EXCEL achtig document).
2) ik wil een berekening uitvoeren op basis van de data in dat document.
3) mbv AJAX maak ik een request naar de server met de bijbehorende data.
4) de server maakt de berekening
5) data wordt geretourneerd in een div (met tabelopmaak ivm. de vele waarden)
6) javascript geeft een melding gebaseerd op de uitkomst!

als er iets niet duidelijk is, hoor ik het graag, bedankt!

p.s. het pakket is dus al superuitgebreid, werkt prima alleen ondervind problemen op andere servers icm firefox

[ Voor 4% gewijzigd door wboard op 27-08-2007 20:56 ]

[JKVA]

Michali schreef op maandag 27 augustus 2007 @ 11:07:
[...]
Je zegt dat het niet efficiënt werkt, maar uit eigen ervaring kan ik je toch wel melden dat het zeker wel efficiënt werkt als je het goed in elkaar zet. Ook kan ik je melden dat jouw methode je echt de kop op gaat breken als je applicatie wat groter wordt en je op verschillende plaatsen wat wijzigingen moet gaan doorvoeren. Gestructureerd werken bespaart je in zo'n geval veel problemen en dus veel tijd.
[...]

Dit klinkt te kort door de bocht. Gestructureerd werken en het oversturen van acties (want dat zijn het in feite) hoeven elkaar niet in de weg te zitten.

Met een data gerichte aanpak (wat XML en JSON zijn) ontkoppel je aan de ene kant de client en de server. Dat is goed, maar aan de andere kant introduceer je een extra marshallinglaag die je moet onderhouden. De server stuurt tenslotte iets anders terug en dat is vrij zinloos als je je client side code daar niet op aanpast, dus die moet ook mee. Die het als het DTO pattern (PoEAA), waar ook veel commentaar op is.

Het doorsturen van JavaScript die direct bijv. je DOM manipuleert koppelt aan de andere kant je client en server side code meer aan elkaar, maar is dat een probleem? De twee zijn namelijk qua lifecyclee ook al voor een groot deel aan elkaar verwant. Dan mag er van mij best wel een redelijke cohesie bestaan. Nu ik er over denk, zie ik een redelijke overeenkomst met het Command pattern (GoF).

Ik predik niet dat je allemaal logica over moet sturen, maar per definitie afbranden is volgens mij niet fair. Overigens vind ik doorgaans het doorsturen van HTML de meest pragmatische oplossing. (geen code duplicatie, weinig client side logica, applicaties binnen no-time AJAX enabled...)

[Michali]

Het is maar net hoeveel views je van dezelfde gegevens wilt maken. Als je puur gegevens stuurt, dan kun je ook andere delen van je applicatie daar op aansluiten. Als blijkt dat je bepaalde gegevens al ergens vandaan kunt krijgen, ongeveer hetzelfde als op degene die op een andere plek gebruikt worden, dan kun je daar gebruik van maken. Het is dan wel zaak om je gegevens bron (voor de situatie) zo algemeen mogelijk te maken.

Het doorsturen van Javascript logica naar de client klinkt mij gewoon niet heel erg logisch in de oren. Want waarom zou je die logica niet al klaar hebben staan en deze gegevens voeren die je via die request ophaalt? Dat deze logica precies moet weten welke gegevens de request terug gaat geven en in welke vorm, dat is inderdaad een redelijke sterke afhankelijkheid, maar daar kom je niet omheen. Het is een afspraak die de betreffende locatie (URL) maakt, een handeling die hij uitvoert en het resultaat dat je kunt verwachten. Een soort van service voor de client om te gebruiken dus. Maar de deze service zou zo min mogelijk moeten afweten van de client. In de praktijk werkt dat natuurlijk wel meestal anders, omdat je de output gaat afstemmen op wat de client nodig heeft, en niet andersom. Maar het is wel degelijk nuttig om de scheiding tussen je gegevens bron en je logica te bewaren. Het versoepelt de koppeling iets meer en het geeft een stuk meer overzicht. Bovendien is het volgens mij zelfs niet eens zo veel meer moeite om het wat 'netter' te doen. Sterker nog, als je van JSON gebruikt maakt is het waarschijnlijk zelf lastiger om logica ipv. pure gegevens terug te sturen. (Dat is mijn ervaring met PHP iig. Geen idee hoe dat in andere talen zit.)

Je zou het idd. een beetje als een Command variant kunnen zien. Voor verschillende handelingen creëer je een service (een command) op de server, welke dan door de client gebruikt kan worden.

[Michali]

wboard schreef op maandag 27 augustus 2007 @ 20:55:
bedankt voor je reactie! een voorbeeld van een actie die ik wil doen:

1) een document staat open en deze wil ik OPSLAAN ALS
2) m.b.v. javascript zorg ik er voor dat het formulier met veel velden (het document dus) uitgelezen wordt en gepost wordt naar de server. De server slaat het vervolgens op in de database (als zijnde een nieuw id, simpel gezegd).
3) het script moet vervolgens returnen dat het document succesvol is opgeslagen als .... (dit in javascript messageBox) en moet vervolgens het nieuwe document laden binnen een bepaalde div...
4) omdat diversen andere divs als gevolg van het wijzigen van het document ook nieuwe data moeten ophalen, stuur ik dus javascript mee die er voor zorgt dat de nieuwe divs ook nieuwe data op gaan halen

Na handeling 3 zou ik zeker geen logica meesturen, maar puur een status van de uitgevoerde actie. Stel dat je het document in andere situaties ook zou willen opslaan, dan krijg je ineens logica mee die in die context helemaal niet wenselijk is. Niet dat dit vaak zou voorkomen, maar als je in deze situatie voor net een andere methode kiest, dan voorkom je dergelijke problemen.

Wat je wilt weten is dit:
- Een status/result code die je verteld of de handeling succesvol is verlopen.

En bij succes wil je dan ook dit weten:
- Het ID van je nieuw opgeslagen document
- De naam van dat document

Deze gegevens moet je dus zien te verzamelen en terug sturen naar de client als de handeling op de server is uitgevoerd. Aan de hand van het resultaat kun je dan je document (je divs) gaan updaten. Ik zie zelf eigenlijk geen reden waarom je op de server al zou bepalen wat je in je scherm gaat doen. Dit kun je beter aan de client zelf overlaten.

een ander voorbeeld:
1) een document staat open (een soort EXCEL achtig document).
2) ik wil een berekening uitvoeren op basis van de data in dat document.
3) mbv AJAX maak ik een request naar de server met de bijbehorende data.
4) de server maakt de berekening
5) data wordt geretourneerd in een div (met tabelopmaak ivm. de vele waarden)
6) javascript geeft een melding gebaseerd op de uitkomst!

Dit is een wat lastiger geval. De meest pragmatische oplossing hier is idd. om gewoon direct HTML als output terug te geven. Echter moet je kijken naar waar je deze gegevens allemaal mogelijk nodig zou hebben. Je zou ook een soort two-step view kunnen maken. Zo zou je een informatie bron kunnen combineren met een view op de server zelf. Zou krijg je altijd HTML terug. Ik zou deze berekening iig. nooit tussen de HTML output zelf doen.

[JKVA]

Michali schreef op dinsdag 28 augustus 2007 @ 08:45:
[...]
Je zou het idd. een beetje als een Command variant kunnen zien. Voor verschillende handelingen creëer je een service (een command) op de server, welke dan door de client gebruikt kan worden.

Ik zit een er een beetje over na te denken. Ik weet nog niet of ik het echt positief vind, deze Command vorm van communicatie. Je bent erg flexibel en ik verwacht ook dat het qua netwerk load niet veel problemen zal veroorzaken, maar je bent ook aangewezen op eval en dat vind ik vrij jammer, vooral omdat je complete scripts incl. logica gaat evalueren. JSON is wat mij betreft een beetje de grens qua evallen.

Bovendien ben ik in de meeste gevallen niet echt gecharmeerd van het command pattern, omdat je de plaats van de logica omdraait. Maar dat is misschien meer door mijn service layer perspectief.

Aan de andere kant, het leent zich wel voor meer component based development, omdat je server side logica en client side logica bij elkaar kunt plaatsen (die hebben namelijk redelijk wat overlap, functioneel gezien). Het enige dat je eventueel op de client nodig hebt, is een generieke bericht handler, of gewoon een eval om je bericht heen.

[Michali]

Meer dan JSON eval ik ook niet, en daar ligt mijn grens idd. ook. Maar volgens mij zitten we langs elkaar heen te praten of interpreteren we bepaalde concepten net op een andere manier, want deze zin:

Het doorsturen van JavaScript die direct bijv. je DOM manipuleert koppelt aan de andere kant je client en server side code meer aan elkaar, maar is dat een probleem?

deed mij juist vermoeden dat je het niet erg vindt om JS te outputten en dit te evallen. Wat bedoelde je hier dan mee?

En naar mijn idee heb ik ook wel een service layer perspectief, maar misschien komt die niet overheen met hoe jij er naar kijkt dus misschien kun je daar iets dieper op ingaan? Een command zie ik in dit geval alleen als een call naar de server, oftewel een aanroep van een bepaalde service. Een erg sterk voorbeeld van een command is het dus nu ook weer niet, want ik wrap deze calls meestal niet echt in eigen klassen, zoals je de meest gangbare varianten van dit pattern zou verwachten. Misschien is dat dus inderdaad niet zo'n goede vergelijking. Maar de services die ik aanroep zijn idd. eigenlijk een soort methodes of commando's die ik asynchroon op afstand aanroep. Dus in dat opzicht zijn het wel weer een soort commands.

[JKVA]

Michali schreef op dinsdag 28 augustus 2007 @ 14:31:
Meer dan JSON eval ik ook niet, en daar ligt mijn grens idd. ook. Maar volgens mij zitten we langs elkaar heen te praten of interpreteren we bepaalde concepten net op een andere manier, want deze zin:

[...]

deed mij juist vermoeden dat je het niet erg vindt om JS te outputten en dit te evallen. Wat bedoelde je hier dan mee?
[...]

In theorie vind ik het niet erg om code te outputten die direct acties op de client doet. In feite krijg je dan een soort 'push' model, want je laat de server bepalen wat de client doet. De HTML wordt sowieso door de server geoutput en je serverside logica (PHP/Java) staat ook op de server (duh), dus je JS, CSS, HTML en PHP/Java staan bij elkaar. Dat wil je, want functioneel gezien zullen ze waarschijnlijk erg veel overlap hebben. De lifecycle van deze onderdelen zal doorgaans gelijk zijn (als je Java aanpast, zal de JS wel mee moeten veranderen), dus uit architectuur perspectief is dit een valide plaats. (ik denk nu vanuit een componentgedachte, ofwel complete, autonome stukken applicatie)

Wat wel een nadeel is, is dat je simpelweg eval() nodig hebt om je response naar volwaardige code en variabelen te converteren. Iemand kan dus willekeurige rotzooi (code snippets) terugsturen waardoor je applicatie gevoeliger wordt voor XSS.

[...]
En naar mijn idee heb ik ook wel een service layer perspectief, maar misschien komt die niet overheen met hoe jij er naar kijkt dus misschien kun je daar iets dieper op ingaan? Een command zie ik in dit geval alleen als een call naar de server, oftewel een aanroep van een bepaalde service. Een erg sterk voorbeeld van een command is het dus nu ook weer niet, want ik wrap deze calls meestal niet echt in eigen klassen, zoals je de meest gangbare varianten van dit pattern zou verwachten. Misschien is dat dus inderdaad niet zo'n goede vergelijking. Maar de services die ik aanroep zijn idd. eigenlijk een soort methodes of commando's die ik asynchroon op afstand aanroep. Dus in dat opzicht zijn het wel weer een soort commands.

De vergelijking met het command pattern die ik trok, komt uit het feit dat de client controle heeft over de logica die uitgevoerd wordt in de scope van de server. Ofwel, de client stuurt een command object met bepaalde statements naar de server en die server voert het uit. De client bepaalt dus de logica.

Mijn opmerking over service layer perspectief komt voort uit het feit dat je dat met business logic niet wilt. Daar wil je gewoon een laag hebben die volledige controle heeft over wat er gebeurt. Een client die dubieuze acties doet, is het laatste dat je dan kunt gebruiken. Dat is tegelijk ook mijn kritiek tegen deze AJAX vorm, aangezien de client (die tenslotte het beste weet wat hij op de pagina kan en moet doen) geen controle meer heeft. Die controle is naar de verzender van de response gegaan, ofwel de server. Ik verwacht dat hierdoor cross-component interacties lastiger worden.

Ofwel, vanuit een architectonisch/component perspectief klinkt het het allemaal wel goed, maar praktisch gezien is het niet echt een fijne manier van werken denk ik.

Beetje dubbelzinnige post, maar ik denk serieus dat deze manier van werken voors en tegens heeft die redelijk gelijkwaardig zijn. Vandaar ook mijn eerste reactie dat je moet oppassen met rake reacties, want een methodiek kan best wel voordelen bieden in een specifiek geval.

Ik bedoel deze reactie:
"Ook kan ik je melden dat jouw methode je echt de kop op gaat breken als je applicatie wat groter wordt en je op verschillende plaatsen wat wijzigingen moet gaan doorvoeren."

[Michali]

Maar de client heeft daar in principe toch altijd controle over, voor zover de server het toelaat? Ik zie niet zo snel hoe deze twee methodieken daar verandering in brengen.

Verder lijkt het me niet dat je vanuit de client bepaalt hoe de logica op de server verloopt. Je roept een bepaalde service aan met bepaalde parameters en het is aan de server dan om te controleren of deze aanroep wel valide is en binnen de context past. Of je het nu in een command model giet of niet, dat verandert de zaak niet. Overigens kun je iedere request naar de server als zo'n command zien. De naam van het command is dan de URL, en de argumenten zijn de parameters. Zo zie ik het ook, en dat is ook de enige manier waarop ik het gebruik.

Maar jouw kritiek is dus dat je, in de vorm van verstrekking van pure gegevens en geen extra code, eigenlijk geen controle hebt over wat er mee gebeurt en dat iemand er mee kan doen wat hij wilt? In sommige situaties zou dat inderdaad het geval zijn, maar het lijkt me dat je hier sowieso heel weinig controle over hebt. Iemand kan met de output doen wat hij wil en het breken zoals hij wil in principe.

Ik snap je punt wel. Ik voer zo min mogelijk business logica (liefst geen) uit op de client. De enige code op de client is voor het verzorgen van de dynamische user interface. Alle uit te voeren business logica gebeurt allemaal op de server in volledige afgesloten handelingen waar volledige controle over is. Deze voer ik dan met de benodigde gegevens en worden dan in zijn geheel uitgevoerd, met een bepaalde resultaat. Hier kan ook heel weinig mis mee gaan. Misschien dat iemand met de parameters gaat klooien, maar een volwaardige check op de input voorkomt eigenlijk altijd dat er iets mis kan gaan.

Ik hou er zelf wel van om bij het laden van de applicatie (de pagina) alle mogelijk benodigde logica (voor de user interface, niet business logica, die blijft op de server) te laden, en daarna alleen verder te gaan met het laden van gegevens en uitvoeren van handelingen op de server. In dat geval dirigeert de client inderdaad wat meer ipv. dat de server wat meer controle heeft over wat er bij de client gebeurt. Hoe ik het zie mag de client gewoon doen wat ie wil, zolang het maar binnen de grenzen blijft van wat de server toelaat en toestaat.

[wboard]

ik zie dus dat hier al meningsverschillen over bestaan, zelf vindt ik het praktisch gezien makkelijker om client-side logica mee te sturen in de return data nav de server request.

kun je een praktisch voorbeeld laten zien? dus hoe je die scheiding voor elkaar krijgt met de bestaande scripting technieken? ik ben zelf geen gediplomeerd programmeur en sommige dingen moet ik op die manier ontdekken..

[crisp]

wboard schreef op dinsdag 28 augustus 2007 @ 21:16:
ik zie dus dat hier al meningsverschillen over bestaan, zelf vindt ik het praktisch gezien makkelijker om client-side logica mee te sturen in de return data nav de server request.

kun je een praktisch voorbeeld laten zien? dus hoe je die scheiding voor elkaar krijgt met de bestaande scripting technieken? ik ben zelf geen gediplomeerd programmeur en sommige dingen moet ik op die manier ontdekken..

Werken met aanstuurdata, pseudo voorbeeld:

JavaScript:

function ajaxHandler(responseText)
{
    var data = parseJSON(responseText);
    if (data && 'action' in data)
    {
        switch (data['action'])
        {
            case 'alert':
                alertHandler(data['actionData']);
                break;
            case 'showContent':
                contentHandler(data['actionData']);
                break;
        }
    }
}

[JKVA]

crisp schreef op dinsdag 28 augustus 2007 @ 22:54:
[...]

Werken met aanstuurdata, pseudo voorbeeld:

JavaScript:

function ajaxHandler(responseText)
{
    var data = parseJSON(responseText);
    if (data && 'action' in data)
    {
        switch (data['action'])
        {
            case 'alert':
                alertHandler(data['actionData']);
                break;
            case 'showContent':
                contentHandler(data['actionData']);
                break;
        }
    }
}

Psies. Volgens het boek Prototype & Scriptaculous in Action heb je de volgende 3 categorieen:

• Script centric: Dat doe je nu. Logica oversturen naar de client. Het geeft je veel vrijheid, maar zorgt voor strakke koppeling tussen server en client. Ben daar doorgaans geen voorstander van. Overigens kan deze manier prima werken, maar dan moet je eigenlijk voor een uniforme interface zorgen zodat de scripts die je overstuurt, op een hoger abstractieniveau met elkaar praten.
• Data centric: Stuur de benodigde data terug naar de client. Vorm is niet interessant, maar XML en JSON (en plain text) zijn vrij gangbaar. Dit is netjes, flexibel en volgens mij verreweg het meest 'netwerk-vriendelijk'.
• Content centric: Stuur gewoon stukken HTML terug en plak die ergens in je pagina. Kost verreweg het minste programmeerwerk, maar biedt niet de vrijheid van de andere twee oplossingen omdat je vast zit aan dat de teruggestuurde HTML letterlijk gecopy pasted wordt in je pagina. Er is eventueel nog wel een mouw aan te passen, maar dan ben je niet echt zuiver meer bezig, mijns insziens.

In dat boek kwamen ze overigens tot de conclusie dat content centric (dus HTML oversturen) de meest pragmatische oplossing is, vooral omdat je weinig code nodig hebt om het aan de praat te krijgen.

[ Voor 5% gewijzigd door JKVA op 31-08-2007 07:52 ]

[wboard]

ik verdiep me er ff in, bedankt voor de info zover

[Michali]

Data centric is dan idd. wat ik het meest gebruik. Puur opvragen van gegevens die je dan gebruikt binnen scripts die al klaar staan bij de client. Vooral als het om een applicatie gaat waar een gebruiker wat langer in zit te werken (bijv. > 15 min.) waarbij veel gegevens geladen moeten worden, dan lijkt mij dit de beste optie.

De andere optie voor mij zou dan idd. content centric zijn, in sommige gevallen een betere optie en het lijkt me idd. een stukje sneller ontwikkelen. Vooral als je gegevens direct in HTML vorm op het scherm weergegeven moeten worden, zonder dat het al te interactief hoeft te zijn, dan is dit een hele geschikte optie.

Script centric zou ik toch zeker niet voor kiezen, klinkt vrij complex, een stuk lastiger te bouwen dan beide andere opties en biedt voorzover ik kan bedenken geen voordelen, dus ik denk dat we het toch wel redelijk met elkaar eens zijn.