[Alg] Webwinkel in html en javascript of php?

Pagina: 1
Acties:
  • 540 views sinds 30-01-2008
  • Reageer

Onderwerpen


Acties:
  • 0 Henk 'm!

Anoniem: 27979

Topicstarter
Er zijn hier al heel wat topics aan gewijd, maar een ding is me nog steeds niet duidelijk. Iedereen raad aan om een webwinkel in Php (en/of ASP?) te maken.
Nu ken ik alleen html, en een groot deel javascript. Is het mogelijk om een simpele webwinkel te maken met alléén html en javascript?

Met simpele webwinkel bedoel ik een paar pagina's met produkten. Je moet de produkten kunnen selecteren en in het winkelmandje kunnen stoppen. En als je klaar bent met winkelen moet op het eindscherm de produkten en de totale kosten komen te staan. Er hoeven geen online betaalmogelijkheden bij te komen daar ik de klanten het bedrag eerst naar mijn rekening wil laten storten.

Kan dit met allen html en javascript? En zoja moet ik het dan in de richting van arrays zoeken of iets anders?

Acties:
  • 0 Henk 'm!

  • djluc
  • Registratie: Oktober 2002
  • Laatst online: 09-07 10:39
Hoe wil je dan die gegevens naar jezelf toe krijgen? Dat is vooral het punt waar JS en HTML tekort schieten.

Acties:
  • 0 Henk 'm!

  • Spider.007
  • Registratie: December 2000
  • Niet online

Spider.007

* Tetragrammaton

Het is goed mogelijk met cookies, en een formulier wat je naar jezelf toe laat mailen. De onderhoudbaarheid zal echter een heel erg stuk slechter zijn dan met wat serverSide code. Waarom leer je dat jezelf niet aan met dit projectje?

---
Prozium - The great nepenthe. Opiate of our masses. Glue of our great society. Salve and salvation, it has delivered us from pathos, from sorrow, the deepest chasms of melancholy and hate


Acties:
  • 0 Henk 'm!

  • blizt
  • Registratie: Januari 2003
  • Laatst online: 11-12-2024

blizt

Wannabe-geek

Natuurlijk kan 't wel, maar vraag niet hoe ;)
Ik ben nu zelf bezig met een webshop in PHP/MySQL, en weet nog niet exact hoe ik 't ga aanpakken, maar ik ben al aardig op weg...
Anyway, let's get on-topic:
Je kan, als je er geen problemen mee hebt de data via de mailclient van de user te versturen, 'n simpel mailform gebruiken.... Als je niet veel klanten hebt, is dit best te doen :)

edit:

Spider: jezelf php/asp/andere taal leren door een webshop te bouwen? Is dat slim? Ik ken al aardig wat php, en ik vind 't nog best ingewikkeld een webshop te maken ... kan je niet beter beginnen met iets simpels als een guestbook of nieuwssysteem ofzo?


edit:

2e edit: als je 't in HTML/JS doet hoort 't in /13, niet in P&W

[ Voor 37% gewijzigd door blizt op 01-05-2004 19:18 ]

United we stand, and divided we fall


Acties:
  • 0 Henk 'm!

  • addictive
  • Registratie: Maart 2003
  • Laatst online: 23-05 19:48
Waarom gebruik je geen php scriptje? Deze hoef je niet zelf te programmeren, er zijn er zat op internet te vinden.

Acties:
  • 0 Henk 'm!

Anoniem: 27979

Topicstarter
Ik wil best een nieuwe taal leren. Maar omdat ik html en javascript al aardig ken vroeg ik me af of het ook daarmee kon. Omdat het inderdaad om weinig produkten gaat, kan ik wel een mailform gebruiken. Alleen dan kan de klant toch geen twee produkten tegelijk bestellen?

Wat programmeertalen betreft duizelt het me een beetje. Welke programmeertaal kan ik dan het beste leren? Alleen Php?

Acties:
  • 0 Henk 'm!

  • addictive
  • Registratie: Maart 2003
  • Laatst online: 23-05 19:48
blizt schreef op 01 mei 2004 @ 19:16:
Je kan, als je er geen problemen mee hebt de data via de mailclient van de user te versturen, 'n simpel mailform gebruiken.... Als je niet veel klanten hebt, is dit best te doen :)
En als die mensen nou ergens internetten op een pc waar geen mailclient voorhanden is, zoals een internet café, of een bieb? Dan kunnen die mensen niks bestellen, dat zijn allemaal dingen waar je rekening mee moet houden. Daarom zou ik php gebruiken.

Acties:
  • 0 Henk 'm!

  • blizt
  • Registratie: Januari 2003
  • Laatst online: 11-12-2024

blizt

Wannabe-geek

Je moet er gewoon één kiezen. Zelf ben ik 't best met PHP, een ander kan je ASP aanraden ... met de search (zoek gewoon op php vs. asp ofzo) kan je heel wat vinden ;)
Maar pas op met 't hier te vragen, voor je 't weet heb je een flamewar gestart.

United we stand, and divided we fall


Acties:
  • 0 Henk 'm!

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 09-07 03:27
Een probleem met een webwinkel in HTML, is dat je er zeker JavaScript bij nodig hebt. Je legt dan een vereiste voor het gebruik bij de klant neer. Als je de pagina's laat genereren met PHP heb je de logica aan de server-kant zitten en hoef je geen JavaScript-ondersteuning te eisen van de klant (al kun je sommige onderdelen nog wel verfraaien). Je hebt dus meer controle over hoe de site gegenereerd wordt en je hebt een grotere groep van gebruikers.

Nu is dit vooral een theoretisch argument, want 95% of meer van de bezoekers van een gemiddelde webshop zal toch met Internet Explorer met JavaScript ingeschakeld browser. (Al ligt dat misschien anders als je een computerspeciaalzaak hebt).

Een praktischer argument is dat je met alleen HTML en JavaScript op de server geen gegevens kan beheren. Het praktische van een webshop is nu juist dat je producten, klanten en bestellingen automatisch op de server kunt laten zitten. De producten staan wel in je JavaScript code, maar gegevens van klanten en bestellingen komen daar niet in terecht. Het is dus al praktisch onmogelijk om een klant een account te geven waarmee die moet inloggen.

Acties:
  • 0 Henk 'm!

  • blizt
  • Registratie: Januari 2003
  • Laatst online: 11-12-2024

blizt

Wannabe-geek

addictive schreef op 01 mei 2004 @ 19:20:
[...]
En als die mensen nou ergens internetten op een pc waar geen mailclient voorhanden is, zoals een internet café, of een bieb? Dan kunnen die mensen niks bestellen, dat zijn allemaal dingen waar je rekening mee moet houden. Daarom zou ik php gebruiken.
Daarom zou ik 't zelf ook niet doen, maar als je weet dat je een erg beperkt publiek hebt, dat jou eventueel persoonlijk zou kunnen contacteren (zet gewoon zoiets van: als u geen emailclient heeft kunt u even een mailtje met uw bestelling sturen naar fake AT nep DOT nl) dan moet 't best kunne.

United we stand, and divided we fall


Acties:
  • 0 Henk 'm!

Anoniem: 27979

Topicstarter
Waarom gebruik je geen php scriptje? Deze hoef je niet zelf te programmeren, er zijn er zat op internet te vinden.
Ik heb al heel lang gezocht naar die scripts. Maar omdat ze vrijwel allemaal in het engels zijn en mijn engels niet top is heb ik er grote moeite mee om ze te laten werken. Ik heb bijvoorbeeld ook osCommerce gedownload en proberen te installeren. Maar die bestaat uit zo ontiegelijk veel files en ik kon er geen touw aan vast knopen, zodat ik er na een week mee klooien mee opgehouden ben.

Op zich leek easyshopmaker (www.easyshopmaker.com) me perfect voor mij, maar daar zit een prijskaartje van rond de 150 euro aan vast die ik niet heb.

Acties:
  • 0 Henk 'm!

  • addictive
  • Registratie: Maart 2003
  • Laatst online: 23-05 19:48
blizt schreef op 01 mei 2004 @ 19:21:
[...]

Daarom zou ik 't zelf ook niet doen, maar als je weet dat je een erg beperkt publiek hebt, dat jou eventueel persoonlijk zou kunnen contacteren (zet gewoon zoiets van: als u geen emailclient heeft kunt u even een mailtje met uw bestelling sturen naar fake AT nep DOT nl) dan moet 't best kunne.
het nadeel is dan weer dat de mensen zelf moeten gaan uitreken wat het kost.
Ik zou gewoon voor php gaan, dan heb je al die problemen niet. En hoef je zelf geen webshop te bouwen.

Acties:
  • 0 Henk 'm!

  • Spider.007
  • Registratie: December 2000
  • Niet online

Spider.007

* Tetragrammaton

blizt schreef op 01 mei 2004 @ 19:16:
[..]

edit:

Spider: jezelf php/asp/andere taal leren door een webshop te bouwen? Is dat slim? Ik ken al aardig wat php, en ik vind 't nog best ingewikkeld een webshop te maken ... kan je niet beter beginnen met iets simpels als een guestbook of nieuwssysteem ofzo?
Je zal toch ergens mee moeten beginnen? Ik probeer vooral aan te geven dat het voor de TS geen onoverkoomlijke drempel moet zijn dat hij/zij momenteel nog geen serverside scripting taal weet te schrijven :)

@TS, wil je van ons horen hoe je dit clientside wilt doen; of wil je een discussie over serverside <> clientside op gang brengen?

---
Prozium - The great nepenthe. Opiate of our masses. Glue of our great society. Salve and salvation, it has delivered us from pathos, from sorrow, the deepest chasms of melancholy and hate


Acties:
  • 0 Henk 'm!

  • blizt
  • Registratie: Januari 2003
  • Laatst online: 11-12-2024

blizt

Wannabe-geek

addictive schreef op 01 mei 2004 @ 19:23:
[...]

het nadeel is dan weer dat de mensen zelf moeten gaan uitreken wat het kost.
Ik zou gewoon voor php gaan, dan heb je al die problemen niet. En hoef je zelf geen webshop te bouwen.
Waarom moeten ze zelf rekenen? Het enige wat ze niet kunnen is de mail versturen, als 't javascript laat zien hoeveel het kost ...
Verder, ik ben het met je eens dat serverside handiger is. Daar valt niet over te twisten hoor.
Spider.007 schreef op 01 mei 2004 @ 19:24:
[...]
Je zal toch ergens mee moeten beginnen? Ik probeer vooral aan te geven dat het voor de TS geen onoverkoomlijke drempel moet zijn dat hij/zij momenteel nog geen serverside scripting taal weet te schrijven :)
Je moet inderdaad ergens beginnen, maar om iemand gelijk in het diepe te gooien?
Als je iemand C gaat leren, laat je 'm toch ook eerst een Hello World maken & niet gelijk een compleet Operating System?

United we stand, and divided we fall


Acties:
  • 0 Henk 'm!

  • dr.lowtune
  • Registratie: Mei 2002
  • Laatst online: 09-07 16:55

dr.lowtune

Deugt niet

Probeer het anders met JSP ;) Moet op zich ook wel te doen zijn. Wellicht is dat voor jou gevoelsmatig makkelijker te leren omdat het enkele kleine overeenkomsten met JS vertoont?

Acties:
  • 0 Henk 'm!

  • addictive
  • Registratie: Maart 2003
  • Laatst online: 23-05 19:48
Anoniem: 27979 schreef op 01 mei 2004 @ 19:23:
[...]


Ik heb al heel lang gezocht naar die scripts. Maar omdat ze vrijwel allemaal in het engels zijn en mijn engels niet top is heb ik er grote moeite mee om ze te laten werken. Ik heb bijvoorbeeld ook osCommerce gedownload en proberen te installeren. Maar die bestaat uit zo ontiegelijk veel files en ik kon er geen touw aan vast knopen, zodat ik er na een week mee klooien mee opgehouden ben.

Op zich leek easyshopmaker (www.easyshopmaker.com) me perfect voor mij, maar daar zit een prijskaartje van rond de 150 euro aan vast die ik niet heb.
Je kunt iemand anders het toch voor je laten opzetten? Of een host nemen dat gebruik maakt van 'cPanel' hiermee kun je zelf allerlei scripts installeren, werkt heel makkelijk en je hoeft zelf niets te doen. Ik weet een host die dat heeft, en al hosting aanbied vanaf 2,5 euro per maand. Ik weet niet of ik hier een link na mag geven, dus ik doe het ook maar niet :) Als je geinteresseerd bent, kun je me een mailtje sturen, dan geef ik je de link wel.

Acties:
  • 0 Henk 'm!

  • blizt
  • Registratie: Januari 2003
  • Laatst online: 11-12-2024

blizt

Wannabe-geek

dr.lowtune: PHP en JS komen ook aardig overeen....

United we stand, and divided we fall


Acties:
  • 0 Henk 'm!

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 09-07 03:27
dr.lowtune schreef op 01 mei 2004 @ 19:27:
Probeer het anders met JSP ;) Moet op zich ook wel te doen zijn. Wellicht is dat voor jou gevoelsmatig makkelijker te leren omdat het enkele kleine overeenkomsten met JS vertoont?
Ik zou daar niet op rekenen! PHP lijkt veel meer op JavaScript dan dat Java op JavaScript lijkt. PHP is voor een JavaScript-programmeur zeker veel makkelijker te leren dan Java. Het JSP framework is naar mijn mening ook nog erg complex, zelfs als je al Java zou kunnen.

Acties:
  • 0 Henk 'm!

  • addictive
  • Registratie: Maart 2003
  • Laatst online: 23-05 19:48
blizt schreef op 01 mei 2004 @ 19:26:
[...]


Waarom moeten ze zelf rekenen? Het enige wat ze niet kunnen is de mail versturen, als 't javascript laat zien hoeveel het kost ...
Je bedoelt dat het javascriptje een opsomming maakt van de producten + kosten, en er dan gevraagd wordt om de tekst te mailen naar blaat[at]blaat[dot]com? Dat zou idd kunnen, maar ziet er wel erg amateuristisch uit, vind je niet?

Acties:
  • 0 Henk 'm!

  • Pelle
  • Registratie: Januari 2001
  • Laatst online: 12:59

Pelle

🚴‍♂️

blitz > onzin :)

JSP is ook niet echt een 'beginners'-taal om een webshop in te bouwen. Met HTML, JS en een mailscript kun je op zich wel wat regelen, maar dan moet je wel een hoop kunstgrepen uithalen. Ik zou gewoon met PHP iets op gaan zetten, het is makkelijk te leren en er zijn talloze webhosts te vinden waar je het zou kunnen testen :)

Acties:
  • 0 Henk 'm!

  • curry684
  • Registratie: Juni 2000
  • Laatst online: 27-05 16:00

curry684

left part of the evil twins

Heropend, ik ben wel benieuwd naar de discussie.

Professionele website nodig?


Acties:
  • 0 Henk 'm!

  • gorgi_19
  • Registratie: Mei 2002
  • Laatst online: 10:16

gorgi_19

Kruimeltjes zijn weer op :9

Goed, even het discussie op een iets abstracter punt brengen; de (on)mogelijkheden van een clientside webwinkel.. :P Mochten mensen allerlei verschillende kant-en-klare webshops bespreken, dan zitten ze in ieder geval verkeerd in dit topic.

Om een kort antwoord te geven op de vraag:
Ja, je kan een clientside webshop maken.
Dit lijkt een simpel antwoord, maar er komen een hele hoop mitsen en maren aan te pas.

Om te beginnen veiligheid. De gouden regel is: "Vertrouw nooit user input". En waar vertrouw je op bij alleen maar clientside gegevens? Juist, alleen maar user input. Wie zegt dat een gebruiker niet stiekem orders wijzigt of prijzen wijzigt. Iedere mogelijkheid van automatisering wordt ongedaan gemaakt door de verplichte (handmatige?) controle.

Het volgende nadeel is actualiteit. Stel we hebben 1 product op voorraad en twee mensen willen hem bestellen. Indien we ook een koppeling maken met een database, wordt het mogelijk om bij de tweede besteller een melding te geven dat het product op is. Indien het alleen een clientside webshop bestaat, dan bestellen beide personen.

Vervolgens komt het probleem van onderhoudbaarheid. Bij een wijziging van de producten zul je relatief meer acties moeten uitvoeren bij alleen een clientside applicatie dan als er ook een serverside backend bij zit.

In een compleet andere hoek kunnen we zoeken naar CRM. Door gegevens van een persoon centraal op te slaan, kunnen op een bepaald moment ook gerichte aanbiedingen aan een persoon gedaan worden. Ook dit vereist of veel werk, of een serverside backend.

In de rest van je verhaal zie ik nog een aantal opvallende zaken staan. Je zegt dat je Javascript goed beheerst. Heb je al overwogen om JScript / ASP te gaan gebruiken?
Sowieso maakt de keuze ASP / PHP niet uit; dit is een kwestie van voorkeur waarbij er in het verleden genoeg discussies zijn geweest, welke eigenlijk altijd in een patstelling eindigen. Eindconclusie is: waar ligt je voorkeur, geen een is significant beter dan de ander.

Een tweede opvallende quote vind ik dat je 150 Euro een redelijk bedrag vindt. Ik denk dat je moet gaan kijken naar een kosten-baten analyse. Een voorbeeldje: Je hebt de keus om zelf wat te maken en een winst van 1000 te realiseren, of je hebt de keuze om een externe applicatie in te kopen a 300 euro en een winst van 1400 te realiseren. Welke optie is dan het meest aantrekkelijk?

Ander iets: is het van belang om veel automatisch te laten gebeuren? Ja, handwerk is relatief gezien duur. Wil je een goede concurrentiepositief houden, dan zul je concurrende prijzen moeten kunnen aanbieden en zo efficient mogelijk moeten werken.

Al met al redenen om van het principe van een puur clientside webshop af te stappen.

[ Voor 7% gewijzigd door gorgi_19 op 02-05-2004 01:41 ]

Digitaal onderwijsmateriaal, leermateriaal voor hbo


Acties:
  • 0 Henk 'm!

  • Spider.007
  • Registratie: December 2000
  • Niet online

Spider.007

* Tetragrammaton

gorgi_19 schreef op 02 mei 2004 @ 01:20:
Goed, even het discussie op een iets abstracter punt brengen; de (on)mogelijkheden van een clientside webwinkel.. :P Mochten mensen allerlei verschillende kant-en-klare webshops bespreken, dan zitten ze in ieder geval verkeerd in dit topic.

Om een kort antwoord te geven op de vraag:
Ja, je kan een clientside webshop maken.
Dit lijkt een simpel antwoord, maar er komen een hele hoop mitsen en maren aan te pas.

Om te beginnen veiligheid. De gouden regel is: "Vertrouw nooit user input". En waar vertrouw je op bij alleen maar clientside gegevens? Juist, alleen maar user input. Wie zegt dat een gebruiker niet stiekem orders wijzigt of prijzen wijzigt. Iedere mogelijkheid van automatisering wordt ongedaan gemaakt door de verplichte (handmatige?) controle.
Alhoewel het wel degelijk is met JavaScript om eea te 'beveiligen' (denk aan hashes ed) zal dit toch vaak via omwegen gaan. Serverside is er uiteraard meer veiligheid om dit soort zaken te controleren. Toch zie ik hier heel veel (PHP) scripts voorbij komen die, door het argeloos vertrouwen van userinput, uiterst kwetsbaar zijn voor XSS en SQL injection attacks. Of zoiets veilig is ligt dus niet per definitie aan de gebruikte taal, maar eerder aan de programmeur :)
Het volgende nadeel is actualiteit. Stel we hebben 1 product op voorraad en twee mensen willen hem bestellen. Indien we ook een koppeling maken met een database, wordt het mogelijk om bij de tweede besteller een melding te geven dat het product op is. Indien het alleen een clientside webshop bestaat, dan bestellen beide personen.
Dit is inderdaad een aardig voorbeeld; alhoewel ik me afvraag:
• Hoeveel (serverside) webwinkels houden hier daadwerkelijk rekening mee (dus dat je bij het plaatsen van de bestelling plotseling de melding krijgt dat het product is uitverkocht?)
• Hoe lastig is het om deze controle door de eigenaar te laten doen? Een webwinkel hoeft (zal) immers niet altijd gekoppelt te zijn aan een voorraadsysteem
Vervolgens komt het probleem van onderhoudbaarheid. Bij een wijziging van de producten zul je relatief meer acties moeten uitvoeren bij alleen een clientside applicatie dan als er ook een serverside backend bij zit.
Wederom; dit is wellicht eenvoudiger met serverside scripting; maar ook in JavaScript is met Arrays en goed programmeren heel wat te doen. Dit kan meteen een dataverkeer optimalisatie betekenen (kijk maar naar de Tweakers frontpage :P)
In een compleet andere hoek kunnen we zoeken naar CRM. Door gegevens van een persoon centraal op te slaan, kunnen op een bepaald moment ook gerichte aanbiedingen aan een persoon gedaan worden. Ook dit vereist of veel werk, of een serverside backend.

In de rest van je verhaal zie ik nog een aantal opvallende zaken staan. Je zegt dat je Javascript goed beheerst. Heb je al overwogen om JScript / ASP te gaan gebruiken?
Sowieso maakt de keuze ASP / PHP niet uit; dit is een kwestie van voorkeur waarbij er in het verleden genoeg discussies zijn geweest, welke eigenlijk altijd in een patstelling eindigen. Eindconclusie is: waar ligt je voorkeur, geen een is significant beter dan de ander.

Een tweede opvallende quote vind ik dat je 150 Euro een redelijk bedrag vindt. Ik denk dat je moet gaan kijken naar een kosten-baten analyse. Een voorbeeldje: Je hebt de keus om zelf wat te maken en een winst van 1000 te realiseren, of je hebt de keuze om een externe applicatie in te kopen a 300 euro en een winst van 1400 te realiseren. Welke optie is dan het meest aantrekkelijk?
Hier ben ik het heel erg mee eens. Het bouwen van een webshop in HTML / Javascript zal heel veel (browser) problemen met zich meebrengen mbt weergave en implementatie verschillen. Deze tijd zal je bij Serversidescripting niet hoeven te besteden. Als 150 Euro veel geld is; kan dit geld beter worden gestoken in serverside; ipv clientside
Ander iets: is het van belang om veel automatisch te laten gebeuren? Ja, handwerk is relatief gezien duur. Wil je een goede concurrentiepositief houden, dan zul je concurrende prijzen moeten kunnen aanbieden en zo efficient mogelijk moeten werken.

Al met al redenen om van het principe van een puur clientside webshop af te stappen.
Het feit dat de TS geen serverside taal kent mag inderdaad niet tot gevolg hebben dat deze shop in JavaScript geschreven gaat worden. Steek die 150 Euro dan in een goed boek, of toch dat kant-en-klare pakket als je niet wilt bijleren op dat gebied :)

---
Prozium - The great nepenthe. Opiate of our masses. Glue of our great society. Salve and salvation, it has delivered us from pathos, from sorrow, the deepest chasms of melancholy and hate


Acties:
  • 0 Henk 'm!

  • blizt
  • Registratie: Januari 2003
  • Laatst online: 11-12-2024

blizt

Wannabe-geek

Spider.007 schreef op 02 mei 2004 @ 10:38:
[...]
Alhoewel het wel degelijk is met JavaScript om eea te 'beveiligen' (denk aan hashes ed) zal dit toch vaak via omwegen gaan. Serverside is er uiteraard meer veiligheid om dit soort zaken te controleren. Toch zie ik hier heel veel (PHP) scripts voorbij komen die, door het argeloos vertrouwen van userinput, uiterst kwetsbaar zijn voor XSS en SQL injection attacks. Of zoiets veilig is ligt dus niet per definitie aan de gebruikte taal, maar eerder aan de programmeur :)
Het ligt natuurlijk aan de programmeur, maar die heeft wel de juiste tools nodig. Als een taal gewoon niet geschikt is om te beveiligen (en geef 't maar toe: JS is dat niet :) ), kan de programmeur wel goed zijn .... 't kan gewoon moeilijk ;)
Ik kan ook geen CMS in alleen HTML maken... Ben het wel met je eens verder, de programmeur moet 't zelf goed doen.

United we stand, and divided we fall


Acties:
  • 0 Henk 'm!

Anoniem: 27979

Topicstarter
Jullie hebben het over beveiliging. Maar dat heb ik op zich toch niet nodig? Mensen betalen vooruit. Ik stuur het produkt pas op zodra de betaling binnen is.

Anyway, ik denk dat ik aan een cursus php begin. En mocht dat niet lukken dan kan ik altijd nog kijken naar dat pakket van 150 euro.

[ Voor 31% gewijzigd door Anoniem: 27979 op 02-05-2004 12:07 ]


Acties:
  • 0 Henk 'm!

  • gorgi_19
  • Registratie: Mei 2002
  • Laatst online: 10:16

gorgi_19

Kruimeltjes zijn weer op :9

Spider.007 schreef op 02 mei 2004 @ 10:38:
Alhoewel het wel degelijk is met JavaScript om eea te 'beveiligen' (denk aan hashes ed) zal dit toch vaak via omwegen gaan. Serverside is er uiteraard meer veiligheid om dit soort zaken te controleren. Toch zie ik hier heel veel (PHP) scripts voorbij komen die, door het argeloos vertrouwen van userinput, uiterst kwetsbaar zijn voor XSS en SQL injection attacks. Of zoiets veilig is ligt dus niet per definitie aan de gebruikte taal, maar eerder aan de programmeur :)
Ja, maar nu ga je voorbij aan mijn punt. Clientside is per definitie onveilig en moet altijd met de grootste zorg behandeld worden. Hoe meer clientside, hoe meer risico op onveiligheid. :) Verhoudingsgewijs kan je een aantal van die potentiele veiligheidsproblemen serverside oplossen. Deze problemen liggen enerzijds op het gebied van SQL Injection / XSS, maar in dit geval acht ik het probleem van foutieve prijzen en incorrecte gegevens vele malen groter.
Dit is inderdaad een aardig voorbeeld; alhoewel ik me afvraag:
• Hoeveel (serverside) webwinkels houden hier daadwerkelijk rekening mee (dus dat je bij het plaatsen van de bestelling plotseling de melding krijgt dat het product is uitverkocht?)
Omgaan met klanten; klanten zijn verwend geraakt. Dit is puur een marketingprobleem; het scheppen van verwachtingen. Als jij een item besteld wat je nodig hebt, en je besteld het bij een webshop, ga je er van uit dat het snel geleverd wordt. Als je het besteld en vervolgens krijg je een berichtje dat het product in bestelling is en over 6 weken geleverd kan worden, omdat het niet op voorraad is, denk je ook van: "Hmmm, had ik het maar eerder geweten, dan had ik verder gekeken".
Oftewel: het scheppen van de juiste verwachtingen. Goede webshops horen hier imho rekening mee te houden.
• Hoe lastig is het om deze controle door de eigenaar te laten doen? Een webwinkel hoeft (zal) immers niet altijd gekoppelt te zijn aan een voorraadsysteem
Dit is minder een programmeerprobleem, maar eerder een bedrijfskundig probleem. Waarop kan men concurreren? Klantrelatie en een webshop? Lijkt me niet. Het aanbieden van verschillende diensten of producten? Nee. Waar kijkt men naar? Betrouwbaarheid en lage kosten. De pricewatch is hier een voorbeeld van. Hoe meer een eigenaar moet doen, hoe relatief duurder een artikel moet worden door de overhead.
Wederom; dit is wellicht eenvoudiger met serverside scripting; maar ook in JavaScript is met Arrays en goed programmeren heel wat te doen. Dit kan meteen een dataverkeer optimalisatie betekenen (kijk maar naar de Tweakers frontpage :P)
Dataverkeeroptimalisatie dmv javascript vind ik vrij achterhaald, eigenlijk. Door middel van http compressie moet je ook een hoop kunnen bereiken, waarbij het verschil verwaarloosbaar klein is.
Verder ga je met je opmerking voorbij aan het punt. Je wilt een prijswijziging maken en dit product in de aanbieding doen. Met een clientside oplossing moet je hiervoor: pagina's downloaden, 2 html pagina's aanpassen, pagina's uploaden.
Een serverside oplossing: geef een vinkje en verander de prijs van een product. Wat is eenvoudiger? Bovendien kunnen meerdere mensen dit, zonder kennis van html / javascript en de foutgevoeligheid neemt af.

[ Voor 3% gewijzigd door gorgi_19 op 02-05-2004 12:04 ]

Digitaal onderwijsmateriaal, leermateriaal voor hbo


Acties:
  • 0 Henk 'm!

  • gorgi_19
  • Registratie: Mei 2002
  • Laatst online: 10:16

gorgi_19

Kruimeltjes zijn weer op :9

Anoniem: 27979 schreef op 02 mei 2004 @ 11:56:
Jullie hebben het over beveiliging. Maar dat heb ik op zich toch niet nodig? Mensen betalen vooruit. Ik stuur het produkt pas op zodra de betaling binnen is.
Zie maar eens dat mensen gaan betalen. Als jij een prutsshopje neerzet, vertrouw ik het voor geen meter en betaal ik liever iets meer en ga wel naar een andere toe. Wat is je uitstraling naar buiten toe?

Een van de problemen met internet is betrouwbaarheid; een aantal mensen hebben hun twijfels hierover. Je moet dus zorgen dat je shop er betrouwbaar en professioneel uit ziet.

[ Voor 17% gewijzigd door gorgi_19 op 02-05-2004 11:58 ]

Digitaal onderwijsmateriaal, leermateriaal voor hbo


Acties:
  • 0 Henk 'm!

  • blizt
  • Registratie: Januari 2003
  • Laatst online: 11-12-2024

blizt

Wannabe-geek

Anoniem: 27979 schreef op 02 mei 2004 @ 11:56:
Jullie hebben het over beveiliging. Maar dat heb ik op zich toch niet nodig? Mensen betalen vooruit. Ik stuur het produkt pas op zodra de betaling binnen is.
Dit gaat meer om de beveiliging van de applicatie op zich. Als je 't dus serverside zou doen, m.b.v. (bijvoorbeeld) PHP & MySQL en jij laat toe dat mensen invullen wat ze maar willen, kunnen ze jouw MySQL-query zodanig 'vervormen' dat ie iets heel anders doet dan jij verwacht had.
Maar ook clientside kunnen er wat problemen komen doordat mensen stiekem prijzen wijzigen, dus je moet altijd eerst even kijken of de prijs wel klopt....

United we stand, and divided we fall


Acties:
  • 0 Henk 'm!

  • addictive
  • Registratie: Maart 2003
  • Laatst online: 23-05 19:48

modbreak:
Als je twijfelt over een link, plaats hem dan ook niet. Overleg van te voren met een mod als je echt twijfelt of iets kan of niet. :)

Verder: Als de TS wil discussieren over welke kant-en-klare webshop hij wil gebruiken, dan zit hij in programming en webscripting fout en gaat dit topic dicht. Wil je deze discussie dan ook niet die kant op duwen? :)

[ Voor 94% gewijzigd door gorgi_19 op 02-05-2004 12:48 ]


Acties:
  • 0 Henk 'm!

Anoniem: 27897

blizt schreef op 02 mei 2004 @ 11:58:
[...]

Dit gaat meer om de beveiliging van de applicatie op zich. Als je 't dus serverside zou doen, m.b.v. (bijvoorbeeld) PHP & MySQL en jij laat toe dat mensen invullen wat ze maar willen, kunnen ze jouw MySQL-query zodanig 'vervormen' dat ie iets heel anders doet dan jij verwacht had.
Maar ook clientside kunnen er wat problemen komen doordat mensen stiekem prijzen wijzigen, dus je moet altijd eerst even kijken of de prijs wel klopt....
Bij client side controles kan je nooit zeker zijn van de invoer van de gebruiker. De code draait immers op de client en die kan hij zelf wijzigen.

Bij server side code kunnen de controles niet omzeild worden en query injection is ook te beveiligen.

Acties:
  • 0 Henk 'm!

  • blizt
  • Registratie: Januari 2003
  • Laatst online: 11-12-2024

blizt

Wannabe-geek

Xenith: sorry, natuurlijk kan je beveiligen tegen SQL Injection. Als je 't goed programmeert (niet vertrouwt op user input) kan serverside heel veilig zijn...

United we stand, and divided we fall


Acties:
  • 0 Henk 'm!

Anoniem: 50873

Anoniem: 27979 schreef op 02 mei 2004 @ 11:56:
Jullie hebben het over beveiliging. Maar dat heb ik op zich toch niet nodig? Mensen betalen vooruit. Ik stuur het produkt pas op zodra de betaling binnen is.

.
en ik betaal pas als ik het binnne heb ;)

geen mogelijk voor rembours ?

zo als jij je klanten nite vertrouwd, vertrouw ik de leverancier niet als ik em niet daad werkelijk face to face zie ;)

suc6 btw en als je scherp gaat prijzen zie je me mischien wel eens

Acties:
  • 0 Henk 'm!

  • elnino
  • Registratie: Augustus 2001
  • Laatst online: 07-07 11:29
Anoniem: 27897 schreef op 02 mei 2004 @ 12:56:
Bij client side controles kan je nooit zeker zijn van de invoer van de gebruiker. De code draait immers op de client en die kan hij zelf wijzigen.
Vandaar lijkt het me dan ook noodzakelijk dat er een controle van de input plaatsvindt, bijvoorbeeld dat iemand het met een rekenmachientje narekent om te kijken wat de prijs wordt.

Met (client-side) Javascript is veel te bereiken, maar zoals ook al eerder gezegd, levert het een hoop knelpunten op.
• Zo is er altijd veel gedoe met compatibiliteit van verschillende browsers. Wat er in Internet Explorer leuk uitziet en goed werkt, kan compleet vastlopen in Mozilla (of andersom natuurlijk). Bedenk ook dat verschillende versies van Internet Explorer ook nog eens anders reageren op Javascript.
• De mogelijkheden zijn beperkt. Zoals gorgi_19 al eerder in deze discussie aangaf zijn een hoop dingen niet of nauwelijks goed te doen in Javascript. Denk dan aan mailscripts (dit zal dan via het mailprogramma van de gebruiker moeten gaan) of een inlogsysteem.
• Een ander belangrijk punt is ook de professionaliteit. Hoewel er met Javascript geweldig mooie dingen te maken zijn, staat PHP gewoon professioneler. Zeker als je er een heel ordersysteem van maakt, waarbij gebruikers kunnen zien wat er met hun pakketje gebeurt.

Het is goed dat je PHP gaat leren, alleen verwacht niet dat je binnen een of twee maanden zelf een winkelsysteem kan maken. Er zijn namelijk genoeg open source-oplossingen voorhande (kijk maar eens op een site als Hotscripts.com) die alle mogelijkheden bieden die je wilt en bovendien vaak goed getest zijn, waardoor er weinig veiligheidsproblemen, waar jij als beginnende programmeur weinig weet van zal hebben, zullen optreden. Kennis van PHP komt dan altijd van pas als je zaken als de configuratie of de lay-out wil aanpassen.

Acties:
  • 0 Henk 'm!

Anoniem: 27979

Topicstarter
Bedankt voor jullie antwoorden. Ik verwacht ook zeker niet dat ik de eerste tijd een goede webwinkel met php zal opzetten. Ik wil het leren zodat ik meer van php ga snappen, en dat als ik dan een phpscript (door iem. anders gemaakt)ga gebruiken, ik die in ieder geval snap. Nu snap ik niets van de code en dan is het moeilijk om dingen aan te passen naar mijn wens.
Ik ga nu rustig beginnen bij het begin, en ik zie wel waar en of het schip strand.

Acties:
  • 0 Henk 'm!

  • JaQ
  • Registratie: Juni 2001
  • Laatst online: 09-07 22:43

JaQ

Om te beginnen: NOFI, maar....

Dat je nog geen taal als asp, jsp of php beheerst zegt waarschijnlijk iets over je ervaring als applicatiebouwer (assumption is the mother of all fuck-ups, maar ik doe deze aanname toch ;) ) Dit houd in dat je waarschijnlijk de skill-set die je nodig hebt om een applicatie zoals een webshop te kunnen bouwen (nog) niet hebt.

Hiermee wil ik dus niet zeggen dat je dom bent of zo, meer dat je hier nog niet aan toe bent. Uitbestenden, downloaden, of kopen zou ik dan als zeer reëele optie gaan beschouwen.

Overigens: Even just-for-the-record: javascript kan ook serversided. Zodra je dat gaat gebruiken kan je best grappige dingen doen (en kan je de o-zo-niet-te-vertrouwen-user-iput toch checken).

Egoist: A person of low taste, more interested in themselves than in me


Acties:
  • 0 Henk 'm!

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 09-07 03:27
Dat is trouwens een aardig punt. Wordt dat tegenwoordig nog gebruikt? Zijn er modules voor populaire webservers als Apache en IIS die server-sided JavaScript ondersteunen? Ik geloof dat het concept zelf door Netscape bedacht was, maar de Netscape webserver wordt bijna nooit meer gebruikt.

Acties:
  • 0 Henk 'm!

  • UltimateB
  • Registratie: April 2003
  • Niet online

UltimateB

Pomdiedom

Om maar even wat moed in te spreken na DrFrankenstoner's post (NOFI ;))

Het leren van een 'prog'-taal (php?) door doen is in mijn ogen toch echt de beste manier. Ik ben ook een webwinkel begonnen. In eerste instantie lekker knullig in html, met dan een klein mailformuliertje waar je 1 product mee kon bestellen. Volgende stap was voor mij het opzetten van een goed voorraad/winkel systeem. Dit heeft best een hoop tijd gekost maar was erg leerzaam. Ik ben nu onderhand (6 maanden na de eerste opening) bezig met het netter schrijven van de site. Hoop bugjes uit de php, daadwerkelijk beveiligen van de site om zo een nog beter systeem neer te zetten.

Eens ben ik het ook met het feit dat uitstraling erg belangrijk is. Vandaar dat ik nu ook css aant leren ben en daarmee wat moois neer probeer te zetten. Ja dit kan ook in html maar daar zit natuurlijk geen uitdaging in ;)

Vergelijk bijv de url in mijn sig maar met die url +/sitev3, komt toch weer een stuk proffesioneler over imo. Hoe dit gaat inwerken op de klantenkring is natuurlijk nog even afwachten :p

Leren is goed, geen vooruitgang == achteruitgang ;)

[ Voor 5% gewijzigd door UltimateB op 04-05-2004 04:57 ]

"True skill is when luck becomes a habit"
SWIS


Acties:
  • 0 Henk 'm!

  • crisp
  • Registratie: Februari 2000
  • Nu online

crisp

Devver

Pixelated

elnino schreef op 03 mei 2004 @ 00:37:
[...]

Vandaar lijkt het me dan ook noodzakelijk dat er een controle van de input plaatsvindt, bijvoorbeeld dat iemand het met een rekenmachientje narekent om te kijken wat de prijs wordt.

Met (client-side) Javascript is veel te bereiken, maar zoals ook al eerder gezegd, levert het een hoop knelpunten op.
• Zo is er altijd veel gedoe met compatibiliteit van verschillende browsers. Wat er in Internet Explorer leuk uitziet en goed werkt, kan compleet vastlopen in Mozilla (of andersom natuurlijk). Bedenk ook dat verschillende versies van Internet Explorer ook nog eens anders reageren op Javascript.
Onzin; alle moderne browsers reageren hetzelfde op javascript, en zelfs IE4 biedt al ondersteuning voor javascript1.3 waarmee je bijna alles al kan. Het enige dat nog echt verschilt is het event-model, maar dat komt pas echt ter sprake als je ingewikkeldere dingen met DHTML wil doen.
IE vanaf versie 5 en alle andere moderne browsers ondersteunen het DOM object model; wie nu nog met document.all en document.layers werkt in JS moet zichzelf eens achter de oren krabben.
• De mogelijkheden zijn beperkt. Zoals gorgi_19 al eerder in deze discussie aangaf zijn een hoop dingen niet of nauwelijks goed te doen in Javascript. Denk dan aan mailscripts (dit zal dan via het mailprogramma van de gebruiker moeten gaan) of een inlogsysteem.
Use the right tool for the job. Het is niet het probleem dat de mogelijkheden van javascript tekort schieten; dan kan ik ook wel voorbeelden aanhalen waarbij PHP tekort schiet. JS met PHP vergelijken is hetzelfde als appels en peren vergelijken. JS en PHP zijn niet interchangeable, ze vullen elkaar juist aan.
• Een ander belangrijk punt is ook de professionaliteit. Hoewel er met Javascript geweldig mooie dingen te maken zijn, staat PHP gewoon professioneler. Zeker als je er een heel ordersysteem van maakt, waarbij gebruikers kunnen zien wat er met hun pakketje gebeurt.
Totaal niet mee eens; aan een site kan je echt niet afzien welke techniek er achter hangt. Dan nog heeft de gebruikte techniek (als ze interchangeable zijn) ook weinig tot niets met professionaliteit te maken. Of is PHP ook professioneler dan JSP of ASP?
Als het om JS en PHP gaat zou je juist deze technieken willen combineren om tot een zo optimaal mogelijk (en dus professioneel) resultaat te komen.
Het is goed dat je PHP gaat leren, alleen verwacht niet dat je binnen een of twee maanden zelf een winkelsysteem kan maken. Er zijn namelijk genoeg open source-oplossingen voorhande (kijk maar eens op een site als Hotscripts.com) die alle mogelijkheden bieden die je wilt en bovendien vaak goed getest zijn, waardoor er weinig veiligheidsproblemen, waar jij als beginnende programmeur weinig weet van zal hebben, zullen optreden. Kennis van PHP komt dan altijd van pas als je zaken als de configuratie of de lay-out wil aanpassen.
Ik raad iedereen aan zich eerst te verdiepen in clientside technieken voordat je met een serverside scripttaal aan de gang gaat. Met PHP genereer je tenslotte ook weer HTML, en zoals gezegd is JS voor veel zaken toch verrekte handig...

Intentionally left blank


Acties:
  • 0 Henk 'm!

  • koli-man
  • Registratie: Januari 2003
  • Laatst online: 25-06 13:32

koli-man

Bartender!!!!

Stel je voor: Je hebt een klant die eigenlijk niet zo goed is met computers
bijvoorbeeld: een meisje van 12 jaar wat redelijk kan leren en binnenkort naar uni gaat :)

Die heeft toevallig onwetend javascript/cookies uitstaan....tja, dan begint de ellende al..e dan?

Hey Isaac...let's go shuffleboard on the Lido - deck...my site koli-man => MOEHA on X-Box laaaiiiff


Acties:
  • 0 Henk 'm!

  • crisp
  • Registratie: Februari 2000
  • Nu online

crisp

Devver

Pixelated

koli-man schreef op 04 mei 2004 @ 11:30:
Stel je voor: Je hebt een klant die eigenlijk niet zo goed is met computers
bijvoorbeeld: een meisje van 12 jaar wat redelijk kan leren en binnenkort naar uni gaat :)

Die heeft toevallig onwetend javascript/cookies uitstaan....tja, dan begint de ellende al..e dan?
tweakers.net is ook niet te bekijken als je JS uit hebt staan, en zonder cookies is inloggen ook niet mogelijk. Je kan in bepaalde mate echt wel van je bezoekers verlangen dat bepaalde zaken clientside ondersteund worden; zeker voor een webwinkel.
Daarnaast dient JS vnl ter aanvulling om de usability te verhogen of om extra functionaliteit toe te voegen aan de basisfunctionaliteit. Gebruik het waar het handig is, en gebruik een serverside oplossing waar het noodzakelijk is.

Intentionally left blank


Acties:
  • 0 Henk 'm!

  • koli-man
  • Registratie: Januari 2003
  • Laatst online: 25-06 13:32

koli-man

Bartender!!!!

crisp schreef op 04 mei 2004 @ 11:36:
[...]

tweakers.net is ook niet te bekijken als je JS uit hebt staan, en zonder cookies is inloggen ook niet mogelijk. Je kan in bepaalde mate echt wel van je bezoekers verlangen dat bepaalde zaken clientside ondersteund worden; zeker voor een webwinkel.
Daarnaast dient JS vnl ter aanvulling om de usability te verhogen of om extra functionaliteit toe te voegen aan de basisfunctionaliteit. Gebruik het waar het handig is, en gebruik een serverside oplossing waar het noodzakelijk is.
ben ik zeker met je eens, gebruik de dingen waar ze voor bedoelt zijn, maar daarom is het ook van stel je voor d :) t

Hey Isaac...let's go shuffleboard on the Lido - deck...my site koli-man => MOEHA on X-Box laaaiiiff


Acties:
  • 0 Henk 'm!

  • crisp
  • Registratie: Februari 2000
  • Nu online

crisp

Devver

Pixelated

koli-man schreef op 04 mei 2004 @ 11:38:
[...]

ben ik zeker met je eens, gebruik de dingen waar ze voor bedoelt zijn, maar daarom is het ook van stel je voor d :) t
Als je op de snelweg wil rijden moet je auto ook harder dan 80 km/uur kunnen; als je site afhankelijk is van bepaalde clientside ondersteuning dan moet je gewoon je bezoekers daar op wijzen (en vaak zijn er wel manieren om die ondersteuning af te vragen). Zeker voor een webwinkel is het accepteren van cookies een must, JS kan je vaak zo toepassen dat zonder clientside JS ondersteuning de basisfunctionaliteit niet verloren gaat.

Intentionally left blank


Acties:
  • 0 Henk 'm!

  • koli-man
  • Registratie: Januari 2003
  • Laatst online: 25-06 13:32

koli-man

Bartender!!!!

crisp schreef op 04 mei 2004 @ 11:46:
[...]

Als je op de snelweg wil rijden moet je auto ook harder dan 80 km/uur kunnen; als je site afhankelijk is van bepaalde clientside ondersteuning dan moet je gewoon je bezoekers daar op wijzen (en vaak zijn er wel manieren om die ondersteuning af te vragen). Zeker voor een webwinkel is het accepteren van cookies een must, JS kan je vaak zo toepassen dat zonder clientside JS ondersteuning de basisfunctionaliteit niet verloren gaat.
Jah dat klopt en ben het dan ook volledig met je eens.

Alleen, geld dit ook als je bijvoorbeeld op een werk zit? (je mag op je werk niets bestellen privé e.d. maar als je het nou wel doet en het is voor het werk :) )
Je hebt niet volledige rechten en de admin heeft dat uitgeschakeld iv.m. beveiliging.
Dan weet ik niet of je dat maar zo in kan schakelen. Ik weet ook niet of dat te beveiligen is. :o (ben geen netwerkbeheerder)
Maar ik denk dat deze opmerkingen dan ook in extreme gevallen zijn en misschien wat te veel off-topic is dus :X maar ja het is toch soort van discussie

[ Voor 4% gewijzigd door koli-man op 04-05-2004 12:12 ]

Hey Isaac...let's go shuffleboard on the Lido - deck...my site koli-man => MOEHA on X-Box laaaiiiff


Acties:
  • 0 Henk 'm!

  • gorgi_19
  • Registratie: Mei 2002
  • Laatst online: 10:16

gorgi_19

Kruimeltjes zijn weer op :9

crisp schreef op 04 mei 2004 @ 11:27:
Ik raad iedereen aan zich eerst te verdiepen in clientside technieken voordat je met een serverside scripttaal aan de gang gaat. Met PHP genereer je tenslotte ook weer HTML, en zoals gezegd is JS voor veel zaken toch verrekte handig...
Dit ben ik niet helemaal met je eens. Als ik naar mijn eigen applicatie kijk, is het clientside gedeelte maar een heel klein gedeelte van het geheel. Bovendien is deze gescheiden van de rest van de applicatie.

Daarnaast ben ik ook benieuwd hoe het zit in dit geval dan met templates; het lijkt me dat een basale kennis van html voldoende is om serverside applicaties te bouwen. Het clientside gedeelte (en koppeling) kan dan door iemand anders gedaan worden.

Digitaal onderwijsmateriaal, leermateriaal voor hbo


Acties:
  • 0 Henk 'm!

  • koli-man
  • Registratie: Januari 2003
  • Laatst online: 25-06 13:32

koli-man

Bartender!!!!

gorgi_19 schreef op 04 mei 2004 @ 12:12:
[...]

Dit ben ik niet helemaal met je eens. Als ik naar mijn eigen applicatie kijk, is het clientside gedeelte maar een heel klein gedeelte van het geheel. Bovendien is deze gescheiden van de rest van de applicatie.

Daarnaast ben ik ook benieuwd hoe het zit in dit geval dan met templates; het lijkt me dat een basale kennis van html voldoende is om serverside applicaties te bouwen. Het clientside gedeelte (en koppeling) kan dan door iemand anders gedaan worden.
Maar je mag er wel een beetje van uitgaan vind ik, dat als iemand in serverside scripting wat voor elkaar krijgt, dat hij ook natuurlijk het een en ander van clientside scripting af weet.
Natuurlijk hebben beide hun makkelijke en moelijke dingen, maar ik denk niet dat het een het ander kan uitsluiten. (tja met templates idd, maar dan heb je toch ook al kennis ervan lijkt me )

Hey Isaac...let's go shuffleboard on the Lido - deck...my site koli-man => MOEHA on X-Box laaaiiiff


Acties:
  • 0 Henk 'm!

  • blizt
  • Registratie: Januari 2003
  • Laatst online: 11-12-2024

blizt

Wannabe-geek

koli-man schreef op 04 mei 2004 @ 12:07:
[...]
Alleen, geld dit ook als je bijvoorbeeld op een werk zit? (je mag op je werk niets bestellen privé e.d. maar als je het nou wel doet en het is voor het werk :) )
Je hebt niet volledige rechten en de admin heeft dat uitgeschakeld iv.m. beveiliging.
Dan weet ik niet of je dat maar zo in kan schakelen. Ik weet ook niet of dat te beveiligen is. :o (ben geen netwerkbeheerder)
Maar ik denk dat deze opmerkingen dan ook in extreme gevallen zijn en misschien wat te veel off-topic is dus :X maar ja het is toch soort van discussie
Als je echt wat moet bestellen op je werk, dan ga je ff naar je sysbeer en vraag of je even rechten mag ;)

United we stand, and divided we fall


Acties:
  • 0 Henk 'm!

  • JaQ
  • Registratie: Juni 2001
  • Laatst online: 09-07 22:43

JaQ

gorgi_19 schreef op 04 mei 2004 @ 12:12:
[...]

Dit ben ik niet helemaal met je eens. Als ik naar mijn eigen applicatie kijk, is het clientside gedeelte maar een heel klein gedeelte van het geheel. Bovendien is deze gescheiden van de rest van de applicatie.
Dat lijkt mij een design keuze... Hoe jij en design keuzes maakt, hoeft uiteraard niet de beste manier te zijn (niet dat ik altijd de beste keuzes maak, maar het gaat nu even om het principe). Neem nu bijvoorbeeld eens het controleren van een waarde die in een form wordt ingevuld. Grofweg gezegt kan dat op 3 plaatsen worden gechecked:

1. clientside (b.v. met javascript)
2. middletier (b.v. met php of een andere servertaal)
3. database (met database triggers )

Echt correct is het om het op alle drie de plaatsen te doen, maar ik lees hierboven dat jij enkel 2 (en misschien 3) gebruikt. Volgens het boekje is dat niet correct. (aangezien we hier toch al accademisch aan het lullen zijn, kan dit er nog wel bij ;) )

Ik ben het overigens wel met je eens dat je een interface moet laten maken door een specialist (en dat is over het algemeen geen programmeur). Techneuten GUI's zijn de lelijkste, minst intuitieve GUI's die er zijn gemaakt. Het koppelen van templates aan je middle tier is vaak niet het meest complexe om te doen, maar om een of andere reden kom ik teveel webdesigners tegen die het toch niet helemaal snappen... (maar dat ter zijde, ik wil hier geen discussie bijin slepen over kwaliteiten van webdesigners)

niet gedacht dat ik ooit javascript nog eens ging verdedigen....

Egoist: A person of low taste, more interested in themselves than in me


Acties:
  • 0 Henk 'm!

  • crisp
  • Registratie: Februari 2000
  • Nu online

crisp

Devver

Pixelated

zelfs als het clientside gebeuren door een ander gedaan wordt denk ik dat je als serverside programmeur nog steeds kennis moet hebben van clientside technieken, al is het alleen maar om de juiste keuzes te kunnen maken voor je applicatie in plaats van dat je krampachtig alles serverside gaat proberen op te lossen ;)

Intentionally left blank


Acties:
  • 0 Henk 'm!

  • gorgi_19
  • Registratie: Mei 2002
  • Laatst online: 10:16

gorgi_19

Kruimeltjes zijn weer op :9

DrFrankenstoner schreef op 04 mei 2004 @ 14:27:

Dat lijkt mij een design keuze... Hoe jij en design keuzes maakt, hoeft uiteraard niet de beste manier te zijn (niet dat ik altijd de beste keuzes maak, maar het gaat nu even om het principe). Neem nu bijvoorbeeld eens het controleren van een waarde die in een form wordt ingevuld. Grofweg gezegt kan dat op 3 plaatsen worden gechecked:

1. clientside (b.v. met javascript)
2. middletier (b.v. met php of een andere servertaal)
3. database (met database triggers )

Echt correct is het om het op alle drie de plaatsen te doen, maar ik lees hierboven dat jij enkel 2 (en misschien 3) gebruikt. Volgens het boekje is dat niet correct. (aangezien we hier toch al accademisch aan het lullen zijn, kan dit er nog wel bij ;) )

Ik ben het overigens wel met je eens dat je een interface moet laten maken door een specialist (en dat is over het algemeen geen programmeur). Techneuten GUI's zijn de lelijkste, minst intuitieve GUI's die er zijn gemaakt. Het koppelen van templates aan je middle tier is vaak niet het meest complexe om te doen, maar om een of andere reden kom ik teveel webdesigners tegen die het toch niet helemaal snappen... (maar dat ter zijde, ik wil hier geen discussie bijin slepen over kwaliteiten van webdesigners)

niet gedacht dat ik ooit javascript nog eens ging verdedigen....
toon volledige bericht
Dat N-tier model ken. :) DAL en BLL zijn netjes gescheiden, soms zit er nog een BF tussen. en Automatisch is de PL dan ook gescheiden. Alleen wat is de PL? Imho zijn usercontrols (inclusief serverside validatie van textboxen dus) ook allemaal PL.

Ingevoerde gegevens controleer ik netjes in m'n PL. Randvoorwaarden voor een algoritme komen voor in de BLL. Data integriteit noem ik geen validatie en zit in DAL. Sowieso is het een aparte discussie om stukjes BLL in de DAL op te nemen, bijvoorbeeld dmb SP's.
Om concreet in jouw voorbeeld in te gaan: Is er een geldige waarde ingevoerd in een checkbox? Dit is imho puur PL; ook al mocht dit serverside gaan gebeuren.

N-tier modellen zijn trouwens ook maar afhankelijk van de keuze die je maakt. Mooiste voorbeeld is de laatste versie van Petshop; een vergelijkingsapplicatie tussen de talen MS en Sun. Microsoft heeft toen zo ongeveer een complete mix gemaakt van layers om een zo snel mogelijke applicatie te maken.

Digitaal onderwijsmateriaal, leermateriaal voor hbo


Acties:
  • 0 Henk 'm!

  • JaQ
  • Registratie: Juni 2001
  • Laatst online: 09-07 22:43

JaQ

gorgi_19 --> I qoute my self:
DrFrankenstoner schreef op 04 mei 2004 @ 14:27:
[...]
(aangezien we hier toch al accademisch aan het lullen zijn, kan dit er nog wel bij ;) )
Als je puur naar het boekje kijkt hoort een scheiding te zijn. Dat dit in de praktijk van anders toegepast wordt, betekent niet dat theorie daardoor ook veranderd. Ik wil enkel aangeven dat je de juiste tools op de juiste plek moet toepassen.

Naar mijn (niet zo nederige) mening, is het clientside controleren van userinput d.m.v. javascript een van de zaken die heel netjes in het n-tier model passen.

Het scheelt een hoop irritatie als je snel en direct een melding krijgt als je iets fout doet. Eerst een form submitten en dan een half form met een melding terug krijgen is niet altijd even prettig, laat staan overzichtelijk. (Uiteraard is dit wel een mening).

De aversie van veel server-side scripters t.o.v. javascript is naar mijn mening misplaatst. Vooral omdat ik persoonlijk het idee heb dat veel server-sided scripters nou niet echt de meest geschoolde it-ers zijn (erg boute uitspraak die niet te staven is met feiten, maar iedereen kent de 14 jarige pukkelige buurjongen die wel even een webshop in elkaar hackt met php en wat mysql en vervolgens denk dat ie super-programmeur is en uber-l33t geek is, nofi richting de 14-jarige-pukkelige buurjongens die wel goed bezig zijn ;) ). Conceptueel goede software bouwen is nog steeds een vak, laten we dat niet vergeten.
laten we eens een term als constraints, foreign keys of normalisatie vallen. Iets waar ik nog steeds 100 topics in de week over geopend zie worden door mensen die erg druk zijn met serversided scripting voor hun webshop/fotoalbum/ander vehikel, maar eigenlijk niet zo goed weten wat ze nou met hun database aanmoeten. Zo zijn er nog vele voorbeelden te verzinnen

Ja, iedereen weet dat user-input, zelfs na validatie door javascript niet te vertrouwen is. Dat is echter niet de reden om javascript in te zetten voor validatie. De hoofdreden is het verhogen van het gebruiksgemak van de applicatie. (vind ik). Het gemak waarmee tegenwoordig iedereen zelf wat in elkaar vrot en dat als "professioneel" de wereld in flikkert stuit met toch een beetje tegen de borst, vooral omdat 90% daarvan ronduit crap is. Nogmaals, ik ben misschien ook geen goeroe, maar ik ken mijn concepten en methodes wel.

Zelf heb ik ondertussen met allerlij verschillende serversided talen web-programmatuur gebouwd, o.a. jsp, php, pl/sql (ja je kan vanuit een oracle database met pl/sql een web-app bouwen). Bij al die programmatuur is javascript onderdeel van het geheel. De interface is over het algemeen het minst leuke voor een programmeur, maar wel het meest krusiale (brakke interface is voor een gebruiker als snel hetzelfde als een brak programma).

Egoist: A person of low taste, more interested in themselves than in me


Acties:
  • 0 Henk 'm!

  • gorgi_19
  • Registratie: Mei 2002
  • Laatst online: 10:16

gorgi_19

Kruimeltjes zijn weer op :9

Voor de duidelijkheid; (ik gok dat ik dat weer eens niet ben geweest.. ;))

Ik doe alleen validatie voor de BLL. Javascript validatie en doe ik niet, puur en alleen om dat ik het een templatekwestie vind en ik me niet bezig houd met templates.
Sowieso pakt .Net al een hoop validatie over.

Ik ben zelf niet tegen het gebruik van Javascript voor validatie. Integendeel. In de meeste gevallen is het een gunstig iets. Ik vertrouw het alleen nooit; dat ik het serverside alsnog controleer (of laat controleren) is een tweede.

Als we toch puur en strikt gaan kijken; niet alleen een template is imho de PL. Ook een stukje PHP kan tot de PL horen. De scheiding: PHP == serverside == BLL en HTML == Clientside == PL gaat imho niet op.

[ Voor 17% gewijzigd door gorgi_19 op 04-05-2004 15:35 ]

Digitaal onderwijsmateriaal, leermateriaal voor hbo

Pagina: 1