[js] het imago van javascript

[Clay]

in dit topic komt het her en der een beetje aan het licht, onder anderen:

Anders
Dat magere product wordt voor menig opdrachtgever verdoezeld door een spetterende Flash-intro en veel "geavanceerde" DHTML-gadgets.

veryip
geen superingewikkelde scripts waar de profs van lopen te watertanden; gewoon doeltreffend, simpel programmeren; de site zo snel mogelijk maken en gewoon duidelijk, helder en 100% gebruiksvriendelijk presenteren op een website; en daar heb je helemaal geen DHTML, XML, java, PHP, ASP etc. voor nodig;

de_das
dhtml is leuk voor hobby sites maar als het echt moet werken hou ik me bij gewone html eventueel hier een daar een spaarzaam gebruikt javascriptje maar that's it.

...

een site moet ook functioneren zonder javascript. javascript is leuk voor mouse-over buttons etc. zeg maar de add-ons. als het niet werkt merk je het als gebruiker niet eens.

In feite beweer je, als je zegt dan javascript en dhtml meer overbodig en niets toevoegend zijn, dat de mensen die deze technieken ontwikkelen eigenlijk overbodig en nutteloos werk aan het doen zijn in het standaardiseren en uitbreiden van de mogelijkheden die het biedt. Vooral de 2e quote van de_das windt er wat dat betreft geen doekjes om.

Zelf vind ik dat een site het helemaal niet hoeft te doen als javascript uitstaat. De techniek biedt mogelijkheden, en als het toegankelijk is gaan mensen het gebruiken.
Wat daar uitrolt, en de waarde daarvan zit hem volledig in de mensen die het ontwikkeld hebben, en niet de techniek zelf. En met alle overbodige scripts die er zijn is dat wel wat er gebeurt, het is zgn de fout van javascript, en daar struikel ik over Een slecht cms is immers ook niet de fout van PHP of ASP, maar de fout van de maker.

Bluestorm
al biedt DHTML met de steeds sneller wordende computers en betere browsers juist mogelijkheden om zaken overzichtelijker te maken

Precies, en dat klinkt al veel beter. Sneller computers zijn zelfs niet eens nodig, het is gewoon de gehele instelling en de wil waarmee je nuttige dingen kan ontwikkelen. Ook de usability is niet per definitie slachtoffer bij het gebruik van dhtml, ik durf zelfs het tegendeel te beweren.

Maar ik hoop toch niet dat ik hier alleen in sta ?

[crisp]

Ik ben het helemaal met Clay eens. Als javascript en dhtml niks zouden toevoegen aan websites dan hadden we wat betreft operating systems ook op kunnen houden bij Dos...

Met behulp van JS en dhtml kan je juist de functionaliteit van je webpagina enorm opschroeven. Dat sommige designers niet weten hoe ze daar mee om moeten gaan, en het dus verkeerd gebruiken (overdoing it) wil niet zeggen dat de technieken nutteloos zijn...

[Verwijderd]

[b]Op donderdag 21 februari 2002 13:29 schreef Clay

Precies, en dat klinkt al veel beter. Sneller computers zijn zelfs niet eens nodig, het is gewoon de gehele instelling en de wil waarmee je nuttige dingen kan ontwikkelen. Ook de usability is niet per definitie slachtoffer bij het gebruik van dhtml, ik durf zelfs het tegendeel te beweren.

Maar ik hoop toch niet dat ik hier alleen in sta ?

Je staat cker niet alleen. Kijk eens op de site van
www.wellowell.nl.
Dmv JavaScript wordt daar een vragenlijst opgebouwd aan de hand van eerder beantwoorde vragen. De vragen die niet beantwoord hoeven worden, worden automatisch onzichtbaar.
Dat is toch echt wel usable. Ikzelf wilde deze techniek ook gaan gebruiken, maar er zit een maximum aan het aantal groepen waarin je layers kunt 'samenvoegen' (1 of meerdere layers zichtbaar maken die in dezelfde groep zitten en die dan automatisch allemaal opschuiven.)

[crisp]

Dat is inderdaad een goed voorbeeld. Internet is allang niet statisch meer, maar een interactief medium. Om die interactie te bewerkstelligen heb je dus dynamiek nodig, en dat bereik je bijvoorbeeld door gebruik te maken van JS en dhtml (niet met een animated gifje). "Het oog wil ook wat" is denk ik hier een gepaste uitdrukking, en mooie effecten horen daar ook bij (mits niet overdone)...

JS en dhtml zijn ook zeker goed downwards compatible toe te passen (mits je weet hoe), dus wat dat betreft is er geen reden om geen gebruik te maken van de technieken die ons ter beschikking staan....

[Verwijderd]

Op donderdag 21 februari 2002 13:43 schreef partyganger het volgende:

[..]

Je staat cker niet alleen. Kijk eens op de site van
www.wellowell.nl.
Dmv JavaScript wordt daar een vragenlijst opgebouwd aan de hand van eerder beantwoorde vragen. De vragen die niet beantwoord hoeven worden, worden automatisch onzichtbaar.
Dat is toch echt wel usable. Ikzelf wilde deze techniek ook gaan gebruiken, maar er zit een maximum aan het aantal groepen waarin je layers kunt 'samenvoegen' (1 of meerdere layers zichtbaar maken die in dezelfde groep zitten en die dan automatisch allemaal opschuiven.)

In dit geval heb je zeker gelijk, er zijn vele nuttige dingen te maken met JS en DHTML.

Ik denk dat de mensen die negatief over JS of DHTML zijn vooral doelen op zaken als:
• gekleurde scrollbars (no offence intended Clay )
• dingen die achter je cursor aanhobbelen zoals in " [topic=417114/1/100] " te zien is...
• Chroomless popup windows...
• etc...

Dit zijn natuurlijk allemaal wel kewle dingen, dat geef ik toe, maar het komt de usability niet ten goede.

Dus, JS en DHTML kunnen zeer zeker goed gebruikt worden, maar er zijn ook vele mensen die er "misbruik" van maken, wat niet ten goede komt aan de usability...

Verder zie ik in de quotes nog zaken staan over serverside scripting talen... Daarvan vind ik dat je die niet kan vergelijken met JS of DHTML. Deze kunnen zeer zeker nuttig zijn, zeker icm met databases. Probeer anders maar een een goed CMS te maken zonder PHP/ASP/etc en zonder een database...

Dus wat veryip zegt daarover, daar ben ik het niet mee eens.

[Blue-eagle]

Ik vergelijk javascript met drank:
• een fles breezer is lekker, en "gewoon" standaard. (standaard site zonder javascript add-ons)
• een glas champagne is ook smakelijk, maar erg exclusief. (site met javascript thingies etc)

Wat is het doel van javascript? Vergelijk het maar weer met drank:
• `t is lekker, op zijn tijd. Maar je moet niet overdrijven.
• Indien slecht gebruikt, maak je meer slachtoffers dan vrienden.

Waarom zou je het gebruiken? Is het nodig? Naar de drank kast dan maar weer..
• Het is gewoon lekker, en het kan weleens handig zijn. Sommige mensen kunnen bepaalde dingen niet zonder.
• Als je het goed gebruikt, hebben andere mensen er ook plezier van - jij blij, zij blij.

Oke, het is een beetje krom misschien.. uhm, het is krom.. maar het maakt wel duidelijk dat javascript gemist kan worden, evenals DHTML toepassingen.
Je kunt het in sommige gevallen handig gebruiken, denk aan formulier controle of iets dergelijks.

Mijn conclusie:
wanneer het nuttig is en het mij en m`n werkgever tijd kan besparen, dan gebruik ik het. Voegt het niks toe, of kan het anders opgelost worden binnen een korter tijdsbestek, dan doe ik dat.
Webdesign is voor mij in ieder geval all `bout the money. En voor m`n werkgever dus ook. Als de klant wilt dat ik exclusief ga doen, betaalt ie daarvoor.
In clay zijn geval is het waarschijnlijk wel veel gevraagd, hij is ook goed in datgene wat hij doet. Ik kan het niet, en ik doe het dus ook zo weinig mogelijk.

Final conclusion:
drank maakt meer kapot.. nee.. ehm, gebruikt, maar met mate.
Ofzo U get the clue, I hope?

[drm]

Blue-eagle schreef een vergelijking
Ik vergelijk javascript met drank:
• een fles breezer is lekker, en "gewoon" standaard. (standaard site zonder javascript add-ons)<li> een glas champagne is ook smakelijk, maar erg exclusief. (site met javascript thingies etc)

</li>
Dus eigenlijk moet je breezer met champagne gaan mengen getver
^</flauw>

Ik ben van mening dat JavaScript functionaliteit kan bieden, die zolang ze functioneel gebruikt wordt ook functioneel is op een website.
^{(om maar eens even heel duidelijk te zijn *kuch* )}

[Verwijderd]

Wellowell is inderdaad een heel goed voorbeeld. Ik heb zelf een aantal maanden aan die site gewerkt (voordat ik mij echt begon te verdiepen in Javascript en DHTML) en ik ben daar pas echt overtuigd geraakt van het nut ervan.

Ik ben het zeker met je eens, Clay, dat DHTML de extra functionaliteit biedt die (grote) sites overzichtelijker en beter navigeerbaar maakt.

Op dit moment worstel ik echter met het vraagstuk: hoe maak ik mijn sites (zoveel mogelijk) standards-compliant en toegankelijk voor minder functionele browsers, terwijl ik zo min mogelijk functionaliteit verlies?

[edit]Nog steeds het beste voorbeeld voor mij dat DHTML echt toegevoegde waarde biedt is de site van International Herald Tribune. Bomvol functionaliteit en gadgets, maar (bijna) allemaal daadwerkelijk handig.

[Woudloper]

Clay ik ben het volledig met je eens.

DHTML en Javascript leveren zeker een toevoeging met betrekking tot het gebruik van een website. Het is naar mijn idee meer een mening van mensen welke er niet genoeg kennis van hebben dat het geen toegevoegde waarde is.

Mochten de mensen meer kennis hebben, zoals jij bijvoorbeeld heb gedaan met je huisje en beehive, dan zie je wat de mogelijkheden zijn...

Ik zou bijvoorbeeld ook niet weten hoe de website van funda eruit gezien zou moeten hebben zonder gebruik te maken van javascript.

http://www.funda.nl/woningen/zoeken/

[drm]

Woudloper:
http://www.funda.nl/woningen/zoeken/

Dat vind ik niet zo'n goed voorbeeld. Die site had prima zonder js ook heel goed kunnen werken.

[Verwijderd]

Op donderdag 21 februari 2002 14:12 schreef Blues het volgende:
Wellowell is inderdaad een heel goed voorbeeld. Ik heb zelf een aantal maanden aan die site gewerkt (voordat ik mij echt begon te verdiepen in Javascript en DHTML) en ik ben daar pas echt overtuigd geraakt van het nut ervan.

HUHJH!!!!! Ik ook man, voor Cambridge Technology Partners!!!
Who the F R U !!!Ben je soms die vriend van Gerbert

[iain]

dit geldt voor alles op het net... animated gif is leuk, als je het goed gebruikt... frames kunnen heel lelijk zijn, maar niet als je ze goed kan gebruiken. Voor Javascript en dhtml geldt hetzelfde. (hier bij GoT wordt volgens mij ook JS gebruikt...)

Bluestorm
al biedt DHTML met de steeds sneller wordende computers en betere browsers juist mogelijkheden om zaken overzichtelijker te maken

op http://www.webreference.com is een hele tutorial over het maken van (heel erg mooie) menu's, zoals bij tweakers.net...

[Verwijderd]

Veel mensen denken bij het woord JS aan leuke popups die nieuwe venstergroottes verneuken, vervelende "body onUnLoad's" etc. zoals wij die gewend zijn bij de doorsnee crack- en p0rnsite.

JS en Dhtml is veel meer dan alleen dat. (zie Clay )

Het is hetzelfde als met Flash, je kan er hele vette shit mee doen, maar de meeste mensen maken een of ander vaag intro-tje ermee, wat alleen afleid en alleen meer tijd en bandbreedte kost.

Ander voorbeeld:
Het moment dat DTP-en ook gewoon betaalbaar op elke huis-, tuin- en keukencomputer kon, begon de slager op de hoek ook meteen zijn nieuwe aanbiedingen te verkondigen door gefotokopieerde a4'tjes te verspreiden met in kleurige word-art, wat natuurlijk meteen zijn kleurigheid verloor, omdat de slager een zwartwit fotokopieerapparaat gebruikte, wat voor vlees nou weer goedkoop bij hem was.
Is het dan zo dat betaalbare DTP-oplossingen meteen zwaar klote zijn? Nee, het gaat er om wat je ermee doet!

zo that's it for now folks

[Verwijderd]

Op donderdag 21 februari 2002 14:42 schreef partyganger het volgende:
HUHJH!!!!! Ik ook man, voor Cambridge Technology Partners!!!
Who the F R U !!!Ben je soms die vriend van Gerbert

Ja, klopt Ik was die HTML'er die de hele tijd zo irritant kwam vragen of jullie je files in wilde checken Jij was op een gegeven moment verdwenen (vakantie ofzo?) met nog 3 of 4 cruciale files uitgecheckt!

Zit je nog steeds bij CTP?

[Verwijderd]

Op donderdag 21 februari 2002 14:57 schreef Blues het volgende:

[..]

Ja, klopt Ik was die HTML'er die de hele tijd zo irritant kwam vragen of jullie je files in wilde checken Jij was op een gegeven moment verdwenen (vakantie ofzo?) met nog 3 of 4 cruciale files uitgecheckt!

Zit je nog steeds bij CTP?

Dat was ik idd . Ik zit niet meer bij CTP, omdat het vet slecht ging/gaat met dat bedrijf, overgenomen door Novell, Woerden office dicht, etc. ze zitten nu alleen nog in Amsterdam. Mn contract liep af en werd niet verlengd en ik werk nu bij New Limit Database Solutions, beetje sites bouwen met FoxPro e.d., voor mezelf veel bezig met PHP en Flash...

[drm]

ehmm, Blues en partyganger>
mag ik jullie verzoeken jullie emotionele weerzien elders voort te zetten? Anders verzandt het leuke onderwerp een beetje ben ik bang

[Verwijderd]

Op donderdag 21 februari 2002 15:07 schreef drm het volgende:
ehmm, Blues en partyganger>
mag ik jullie verzoeken jullie emotionele weerzien elders voort te zetten? Anders verzandt het leuke onderwerp een beetje ben ik bang

Sorry dude, moment of weakness there . Toch altijd grappig om mensen 'tegen te komen' op internet die iets gemeen met je heeft

[Pelle]

Ik wil graag even onderscheid maken tussen JS & DHTML. JS an sich is goed te gebruiken voor bijvoorbeeld form-validation. Zelf doe ik dat niet, ik doe het liever server-side, maar het geeft even aan dat het niet alleen maar fancy truukjes zijn die je met JS uit kunt halen.

DHTML daarintegen is de combinatie van HTML, JS en CSS. Dynamisch properties van pagina elementen wijzigen dus. En dat kan functioneel zijn, maar hoeft niet.

Hierarchische menu's zijn voor veel sites een uitkomst bijvoorbeeld, of het showen/hiden van layers om extra tekst & uitleg te geven over het item waar je muis nu op staat vind ik persoonlijk ook erg nuttig.

Je kunt het overdrijven door te gaan DHTML'en om het DHTML'en. En dat moet je laten, tenzij het voor eigen projectjes is natuurlijk

[drm]

partyganger:
Sorry dude, moment of weakness there . Toch altijd grappig om mensen 'tegen te komen' op internet die iets gemeen met je heeft

snap ik 't moest alleen niet richting topic-title change in "Mooi weerzien oude collega's" gaan
^</offtopic>

Pelle:
Ik wil graag even onderscheid maken tussen JS & DHTML. JS an sich is goed te gebruiken voor bijvoorbeeld form-validation. Zelf doe ik dat niet, ik doe het liever server-side, maar het geeft even aan dat het niet alleen maar fancy truukjes zijn die je met JS uit kunt halen.

true.
^{(btw, waarom doe je dat liever serversided? just curious )}

DHTML daarintegen is de combinatie van HTML, JS en CSS. Dynamisch properties van pagina elementen wijzigen dus. En dat kan functioneel zijn, maar hoeft niet.

Hierarchische menu's zijn voor veel sites een uitkomst bijvoorbeeld, of het showen/hiden van layers om extra tekst & uitleg te geven over het item waar je muis nu op staat vind ik persoonlijk ook erg nuttig.

Je kunt het overdrijven door te gaan DHTML'en om het DHTML'en. En dat moet je laten, tenzij het voor eigen projectjes is natuurlijk

ben ik mee eens. (jemig, alweer )

[raptorix]

Javascript is een tool, een tool die je spaarzaam moet gebruiken voor de zaken waar het nodig is en waar het geschikt voor is.

Om voorbeeld te geven, javascript is prima voor zaken als formvalidatie, de server wordt minder belast en de user hoeft geen extra requests te doen.

[Pelle]

Op donderdag 21 februari 2002 15:21 schreef drm het volgende:
^{(btw, waarom doe je dat liever serversided? just curious )}

Voor mensen zoals de_das, die JS uit hebben staan

Nee, meer mogelijkheden, en je weet dan zeker dat er geen verkeerde dingen in je database en/of mailtje komen. En aangezien vrijwel al m'n scripts toch custom-build zijn, ga ik geen JS-validation toepassen als ik dat ook gewoon serverside kan doen. PHP of Perl hebben overigens ook iets meer mogelijkheden tot string-manipulatie dan JS.

En zeg nou zelf, wat is makkelijker:

code:

function checkThisThingie() {
    if (document.forms['blab'].elements['doed'].options[document.forms['blab'].elements['doed'].selectedIndex].value == "melp") {
      // code
    }
}
<form name="blab" onSubmit="return checkThisThingie();">
  <select name="doed">
    <!-- blah -->
  </select>
</form>

of

PHP:

<?
if ($doed == "melp") // code
?>

[drm]

Pelle: meer mogelijkheden, en je weet dan zeker dat er geen verkeerde dingen in je database en/of mailtje komen.
(snip)
PHP of Perl hebben overigens ook iets meer mogelijkheden tot string-manipulatie dan JS.

zoals
* drm had er wel wat voor over gehad als strings hetzelfde zouden werken in PHP als in JS.

En zeg nou zelf, wat is makkelijker:

code:

meuk

of

PHP:

<?
if ($doed == "melp") // code
?>

tja, maar het is voor de gebruiker vaak wel rielekst dat ze hele lange forms niet opnieuw hoeven in te vullen. En als je de waarden in het formulier serversided weer in gaat vullen gaat er denk ik toch uiteindelijk niet veel minder code mee gemoeid dan wanneer je het clientsided doet.

[Verwijderd]

Op donderdag 21 februari 2002 15:48 schreef drm het volgende:

[..]

zoals
* drm had er wel wat voor over gehad als strings hetzelfde zouden werken in PHP als in JS.
[..]

tja, maar het is voor de gebruiker vaak wel rielekst dat ze hele lange forms niet opnieuw hoeven in te vullen. En als je de waarden in het formulier serversided weer in gaat vullen gaat er denk ik toch uiteindelijk niet veel minder code mee gemoeid dan wanneer je het clientsided doet.

misschien is dat wel waar, als je de waardes weer serverside wil terugzetten, dat dat misschien wel erg veel coden is, maar wat (zoals pelle al zei) mensen JS uit hebben staan?
En nee, die zijn niet te verwaarlozen imho.Als ik nou voor de lol eens kijk naar de mediatheek bij ons op school. Daar hebben wij bijvoorbeeld nu pas JS aan staan, na veel zeuren bij de sys.beheerder.

Trouwens als je nou bijv. php een pagina laat zien met wat je niet hebt ingevult en de mededeling dat je even op je backbutton moet drukken, dan krijg je gewoon weer net het formuliertje te zien met de laatst ingevulde waardes, niet dan?

[drm]

Akira:
misschien is dat wel waar, als je de waardes weer serverside wil terugzetten, dat dat misschien wel erg veel coden is, maar wat (zoals pelle al zei) mensen JS uit hebben staan?
En nee, die zijn niet te verwaarlozen imho.Als ik nou voor de lol eens kijk naar de mediatheek bij ons op school. Daar hebben wij bijvoorbeeld nu pas JS aan staan, na veel zeuren bij de sys.beheerder.

imo hangt dat heel erg af van de doelgroep. Misschien zelfs wel handig een doelgroep-onderzoek te doen voor dat soort aangelegenheden.

Trouwens als je nou bijv. php een pagina laat zien met wat je niet hebt ingevult en de mededeling dat je even op je backbutton moet drukken, dan krijg je gewoon weer net het formuliertje te zien met de laatst ingevulde waardes, niet dan?

Tja, dat vind ik dus echt helemaal niet netjes... "Wilt u op de terug- (of back)-knop drukken?"...

Trouwens, het is met database-driven sites niet zo gek om in je header altijd een no-cache op te geven. Dan krijg je -ook wanneer je de back-button gebruikt- toch weer een leeg formulier...

Ik vind het een twijfelgeval. Er is voor beide oplossingen een hoop te zeggen...

[Verwijderd]

Op donderdag 21 februari 2002 16:01 schreef drm het volgende:

[..]

imo hangt dat heel erg af van de doelgroep. Misschien zelfs wel handig een doelgroep-onderzoek te doen voor dat soort aangelegenheden.
[..]

Tja, dat vind ik dus echt helemaal niet netjes... "Wilt u op de terug- (of back)-knop drukken?"...

Trouwens, het is met database-driven sites niet zo gek om in je header altijd een no-cache op te geven. Dan krijg je -ook wanneer je de back-button gebruikt- toch weer een leeg formulier...

Ik vind het een twijfelgeval. Er is voor beide oplossingen een hoop te zeggen...

Dan houden wij het hierbij ok>

[LuCarD]

Op donderdag 21 februari 2002 15:48 schreef drm het volgende:

[..]

zoals
* drm had er wel wat voor over gehad als strings hetzelfde zouden werken in PHP als in JS.
[..]

tja, maar het is voor de gebruiker vaak wel rielekst dat ze hele lange forms niet opnieuw hoeven in te vullen. En als je de waarden in het formulier serversided weer in gaat vullen gaat er denk ik toch uiteindelijk niet veel minder code mee gemoeid dan wanneer je het clientsided doet.

Das dus onzin.....

code:

<?
if ($nummer > 1000) {
// Doe wat
}
?>
<FORM>
<INPUT TYPE="TEXT" NAME="nummer" VALUE="<?= $nummer ?>" />
</FORM>

Hoezo veel langer???

[Pelle]

Op donderdag 21 februari 2002 15:48 schreef drm het volgende:
tja, maar het is voor de gebruiker vaak wel rielekst dat ze hele lange forms niet opnieuw hoeven in te vullen.

Dat is bij mijn forms nooit het geval
Er wordt een error-message gegenereerd, met een back-optie erbij, waarna de gebruiker terugkeert naar z'n form waar alle waarden nog gewoon ingevuld staan zoals hij ze heeft ingevuld.

ICQ me maar ff als je wat voorbeeldjes wilt hebben

[-RenE-]

Op donderdag 21 februari 2002 13:43 schreef partyganger het volgende:

[..]

Je staat cker niet alleen. Kijk eens op de site van
www.wellowell.nl.

Ik ben direct gaan kijken. Resultaat:

De browserversie waarmee u Wellowell probeert te bereiken, wordt helaas niet ondersteund. Om van Wellowell gebruik te maken adviseren wij u om Netscape Communicator 4.76 of Internet Explorer 5.0 of 5.5 te gebruiken. Deze kunt u eventueel downloaden via de links op deze pagina.

Nu ben ik toevallig een klant die een grote order wil plaatsen, dan ga ik toch meteen weg?

Verder vind ik JS als form validatie prima, maar houdt er dan wel rekening mee dat -als ik het uit heb staan of mijn browser het niet ondersteund- ik een order kan plaatsen zonder dat de data gevalideerd is. Dat kan in de praktijk betekenen dat jij voor een prijs moet leveren die je niet gewild had. Ik denk hier even aan een simpele vermenigvuldiging van het aantal producten maal de prijs.
Kortom, naast JS op client niveau heb je dus altijd nog server-side controle nodig.

Bedenk ook eens dat bij heel wat bedrijven javascript uitstaat omdat het als risicovol wordt gezien.

[Verwijderd]

Op donderdag 21 februari 2002 16:01 schreef drm het volgende:
[...]
Tja, dat vind ik dus echt helemaal niet netjes... "Wilt u op de terug- (of back)-knop drukken?"...
[...]

en dan is js dus makkelijk!

code:

<body onLoad="history.go(-1)">

heerlijk, dat javascript, vooral voor dit soort kleine dingetjes

[drm]

Pelle:
Dat is bij mijn forms nooit het geval
Er wordt een error-message gegenereerd, met een back-optie erbij, waarna de gebruiker terugkeert naar z'n form waar alle waarden nog gewoon ingevuld staan zoals hij ze heeft ingevuld.

ICQ me maar ff als je wat voorbeeldjes wilt hebben

neuhh ik kan me voorstellen hoe je dat doet (zonder JS), met een enorme url met key=value paren erin. Ben wel benieuwd hoe je dat oplost bij bijvoorbeeld uploaden van files...

LuCarD:
Das dus onzin.....

code:

<?
if ($nummer > 1000) {
// Doe wat
}
?>
<FORM>
<INPUT TYPE="TEXT" NAME="nummer" VALUE="<?= $nummer ?>" />
</FORM>

Hoezo veel langer???

Da's ook een manier, ja... niet aan gedacht

[-RenE-]

Op donderdag 21 februari 2002 17:13 schreef drm het volgende:

[..]

neuhh ik kan me voorstellen hoe je dat doet (zonder JS), met een enorme url met key=value paren erin. Ben wel benieuwd hoe je dat oplost bij bijvoorbeeld uploaden van files...
[..]

Toverwoord: Session

[iain]

Op donderdag 21 februari 2002 17:11 schreef FoOL het volgende:

[..]

en dan is js dus makkelijk!

code:

<body onLoad="history.go(-1)">

heerlijk, dat javascript, vooral voor dit soort kleine dingetjes

das wel erg cru! bij het laden al weer terug gestuurd worden!

Maar voor automatisch doorlinken naar andere pagina's, of dat nou de vorige in je history is, of een andere, is javascript behoorlijk onmisbaar.

Op donderdag 21 februari 2002 17:05 schreef -RenE- het volgende:

[..]

Ik ben direct gaan kijken. Resultaat:
[..]

Nu ben ik toevallig een klant die een grote order wil plaatsen, dan ga ik toch meteen weg?

Verder vind ik JS als form validatie prima, maar houdt er dan wel rekening mee dat -als ik het uit heb staan of mijn browser het niet ondersteund- ik een order kan plaatsen zonder dat de data gevalideerd is. Dat kan in de praktijk betekenen dat jij voor een prijs moet leveren die je niet gewild had. Ik denk hier even aan een simpele vermenigvuldiging van het aantal producten maal de prijs.
Kortom, naast JS op client niveau heb je dus altijd nog server-side controle nodig.

Bedenk ook eens dat bij heel wat bedrijven javascript uitstaat omdat het als risicovol wordt gezien.

Dat houd je altijd bij clientside, aangezien elke client een andere software heeft. Toch vind ik dat je er vanuit mag gaan dat bepaalde clientside dingetjes, zoals js, wel aanwezig is. Wie heeft er nou niet js-ondersteuning? Je moet dan gewoon oppassen met nieuwe commando's en opties, die oudere/andere browsers niet/anders interpreteren.


Ik wil nog ff benadrukken dat je nooit ooit een script van http://javascript.internet.com onaangepast in je site moet verwerken. De meeste van die scripts zijn juist van het type waarvan je zegt: "laat ze alsjeblieft weg!".

* iain moet bekennen ze ook wel te gebruiken, maar dat is nooit eraan te zien.

[-RenE-]

Op donderdag 21 februari 2002 17:31 schreef IainHecker het volgende:
[..]

Toch vind ik dat je er vanuit mag gaan dat bepaalde clientside dingetjes, zoals js, wel aanwezig is. Wie heeft er nou niet js-ondersteuning? Je moet dan gewoon oppassen met nieuwe commando's en opties, die oudere/andere browsers niet/anders interpreteren.

Ik heb ook wel js, maar draai wel Opera

Ik zou verder toch niet graag mijn e-commerce site van JS willen laten afhangen. Veel te riskant aangezien de client de JS code kan manipuleren.

[Verwijderd]

Op donderdag 21 februari 2002 17:39 schreef -RenE- het volgende:

[..]

Ik heb ook wel js, maar draai wel Opera

Ik zou verder toch niet graag mijn e-commerce site van JS willen laten afhangen. Veel te riskant aangezien de client de JS code kan manipuleren.

Opera is n ramp met JS/DHTML...
als ie al van n simpele functie zoals window.open() de parameters niet goed interpreteerd....

[iain]

Op donderdag 21 februari 2002 19:13 schreef Akira het volgende:
Opera is n ramp met JS/DHTML...
als ie al van n simpele functie zoals window.open() de parameters niet goed interpreteerd....

Dat is zeker lastig. Maar ik dacht dat we net geconcludeerd hadden dat JS zo niet tof is!
Ik ken Opera niet, dus de details weet ik niet.

Op donderdag 21 februari 2002 17:39 schreef -RenE- het volgende:
Ik zou verder toch niet graag mijn e-commerce site van JS willen laten afhangen. Veel te riskant aangezien de client de JS code kan manipuleren.

Nee, een e-commerce site moet je niet van JS laten afhangen, daar heb je helemaal gelijk in, maar ik had ook gezegd, dat niet al te moderne JS-technieken best gaan, zoals fOol zei voor backbuttons, enzo. En om gauw dingen aan je site te veranderen, zonder de hele pagina te verversen. Allemaal goed mogelijk, en niet eens zo riskant!

[Verwijderd]

Op donderdag 21 februari 2002 19:28 schreef IainHecker het volgende:

[..]

Dat is zeker lastig. Maar ik dacht dat we net geconcludeerd hadden dat JS zo niet tof is!
Ik ken Opera niet, dus de details weet ik niet.

hhmmzz toen was ik me shawarma (alternatieve spelling) nog aan het eten denk ik
maar mij hoor je niet zeggen dat js niet tof is. (hoef geen ruzie met Clay )

[iain]

Op donderdag 21 februari 2002 19:36 schreef Akira het volgende:

[..]

hhmmzz toen was ik me shawarma (alternatieve spelling) nog aan het eten denk ik
maar mij hoor je niet zeggen dat js niet tof is. (hoef geen ruzie met Clay )

het leuke van fora is dat je kan lezen wat iedereen van te voren eruit heeft geflapt.

// shoarma is lekker

sorry voor het slap gelul....

JS is het mooist als je er niks van kunt zien. Dus je gebruikt het bijvoorbeeld om sommige dingen te hiden, of om berekeningen te maken (I did)... javascript, met de hand aangepast, gecombineerd met php... daar wordt ik nou opgewonden van

[Clay]

Ik ben blij dat er toch nog veel mensen het met me eens zijn Zelf vind ik het ook het mooist als je trouwens niet echt merkt dat je met dhtml of js te maken hebt, het moet functioneel zijn.
Zo was een van de reacties op mijn site:

eindelijk is een keer goed flash gebruik

En als ik iets niet kan is het wel flash

Formvalidatie in JS is op een bepaalde manier wel jezelf voor de gek houden, je kan immers (in extreme gevallen) altijd zelf de gegevens nog intypen in je urlbalk, dus server side validatie blijft nodig, maar zeker naar de gebruiker toe vind ik het wel "sociaal" om hem realtime te informeren van zijn/haar fouten.

en in waar ik in dit topic over begon heb ik inmiddels helemaal werkend dus client side validatie hoef ik gelukkig nooit meer handmatig te scripten want dat is het aller saaiste en sufste wat er maar is in js.

[Verwijderd]

Op donderdag 21 februari 2002 17:05 schreef -RenE- het volgende:

[..]

Ik ben direct gaan kijken. Resultaat:
[..]

Nu ben ik toevallig een klant die een grote order wil plaatsen, dan ga ik toch meteen weg?

Verder vind ik JS als form validatie prima, maar houdt er dan wel rekening mee dat -als ik het uit heb staan of mijn browser het niet ondersteund- ik een order kan plaatsen zonder dat de data gevalideerd is. Dat kan in de praktijk betekenen dat jij voor een prijs moet leveren die je niet gewild had. Ik denk hier even aan een simpele vermenigvuldiging van het aantal producten maal de prijs.
Kortom, naast JS op client niveau heb je dus altijd nog server-side controle nodig.

Bedenk ook eens dat bij heel wat bedrijven javascript uitstaat omdat het als risicovol wordt gezien.

Je gebruikt zeker NS6, das de enigste browser waar nog geen ondersteuning voor is idd....

[Verwijderd]

Ik kan niet meer zonder JavaScript: dat is het imago van JavaScripting

[Verwijderd]

Op donderdag 21 februari 2002 22:31 schreef Clay het volgende:
[knip]...
en in waar ik in dit topic over begon heb ik inmiddels helemaal werkend dus client side validatie hoef ik gelukkig nooit meer handmatig te scripten want dat is het aller saaiste en sufste wat er maar is in js.
[/knip]

Clay, willing to share

*edit* al gevonden

[Clay]

Op vrijdag 22 februari 2002 09:33 schreef partyganger het volgende:

[..]

Clay, willing to share

*edit* al gevonden

laatste versie staat (nog) niet online.

[Bosmonster]

Formvalidatie in JS is op een bepaalde manier wel jezelf voor de gek houden, je kan immers (in extreme gevallen) altijd zelf de gegevens nog intypen in je urlbalk, dus server side validatie blijft nodig

Het nut van POST


Ben het verder met je eens trouwens hoor.. DHTML en Flash zijn er als ondersteuning, niet als basis. Een hele site in Flash is net zo fout als een hele site in DHTML. Maar zodra het gaat om 'controls' is het goed.

Het ligt niet aan de technieken, maar aan degene die ze gebruikt. Daarom zijn gasten als veryip en de_das zelf nogal fout Maar goed.. dat was al geen geheim meer geloof ik

[Bosmonster]

en in waar ik in dit topic over begon heb ik inmiddels helemaal werkend dus client side validatie hoef ik gelukkig nooit meer handmatig te scripten want dat is het aller saaiste en sufste wat er maar is in js.

Zoiets heb ik ook gemaakt tijdje terug vor mijn scriptibete collega's.. Maak een formulier en geef dit soort dingen op:

fVal["postcode"]= FV_POSTCODE;
fVal["email"]= FV_EMAIL;
fVal["naam"]= FV_EMPTY;
fVal["age"]= FV_NUMBER;

De FV_xxx's zijn standaard FormValidators die checken op syntax/etc, een standaard melding genereren en vervolgens focus weer teruggooit naar die input..

Simpel as that.

[LuCarD]

Op vrijdag 22 februari 2002 10:25 quoted Bosmonster het volgende:
[...]

IMHO

JS is client scripting. en is daar om de client te ondersteunen. Client-side validatie gebruik je om de client makkelijker en sneller data entries te kunnen laten maken. Helaas kan je er nog steeds niet op vertrouwen dat het 100% veilig is. Dus je moet het altijd opvangen aan de serverside met een extra controle.

edit:


mag niet eens nesten van tags

[Verwijderd]

Op vrijdag 22 februari 2002 10:42 schreef LuCarD het volgende:

[..]

IMHO

JS is client scripting. en is daar om de client te ondersteunen. Client-side validatie gebruik je om de client makkelijker en sneller data entries te kunnen laten maken. Helaas kan je er nog steeds niet op vertrouwen dat het 100% veilig is. Dus je moet het altijd opvangen aan de serverside met een extra controle.

edit:


mag niet eens nesten van tags

[/quote]

Je valideert natuurlijk geen creditcards met JavaScript op een geldige algoritme

[raptorix]

Ik gebruik zelf altijd Stored Procedures, grote voordeel is dat clientside validatie kan volstaan, mocht iemand echt zitten fucken met vreemde strings kan dit hooguit leiden tot een error maar nooit tot het resulteren van vreemde queries etc.

[LuCarD]

Op vrijdag 22 februari 2002 10:49 schreef Gordijnstok het volgende:

[..]


Je valideert natuurlijk geen creditcards met JavaScript op een geldige algoritme

Dat is nou een van de dingen die ik nou juist wel zou doen!
Daar maak tijdens het invoeren gemakkelijk een fout mee. En CC zijn heel makkelijk te controleren.

bv als volgt.
• 16-19 cijfers op een rij
• eerste 4 bepaald leverancier (VISA AMEX MASTERCARD etc) (dit is statisch)
• 16-19 getallen voldoen aan een 11 proef of is dat een 10 proef ( )
in elk geval

code:

function isCreditCard(st) {

  if (st.length > 19)
    return (false);

  sum = 0; mul = 1; l = st.length;
  for (i = 0; i < l; i++) {
    digit = st.substring(l-i-1,l-i);
    tproduct = parseInt(digit ,10)*mul;
    if (tproduct >= 10)
    sum += (tproduct % 10) + 1;
    else
    sum += tproduct;
    if (mul == 1)
    mul++;
    else
    mul--;
  }
  if ((sum % 10) == 0)
    return (true);
  else
    return (false);

} // END FUNCTION isCreditCard()

[Verwijderd]

Op vrijdag 22 februari 2002 09:49 schreef Clay het volgende:

[..]

laatste versie staat (nog) niet online.

Maar komt wel I hope. Dat zou echt zoveel tijd schelen nl....

[Clay]

joah nog ff wat extratjes inbouwen, 2talige opmerkingen enzo, of dat je die zelf in kan stellen.