Met vallen en opstaan

Het temmen van ASP begint zowaar te lukken. In het begin zat mijn code vol met onder andere:

Set objConn = Server.CreateObject("ADODB.connection")
objConn.open "DRIVER={SQL Server}; Server=XXXX; Database=XXXX; UID=XXXX; PWD=XXXX;"
Set recordSet = Server.CreateObject("ADODB.recordset")
recordset.open "QUERY_BLAH", objConn
do until recordset.EOF
"haal data op of whatever"
loop
recordset.close
objConn.close
recordset = Nothing
objConn = Nothing

Elke query betekende minstens 8 lijntjes extra code die. Op een eind zat ik met een onoverzichtelijke spaghetti. Dat is zowat het eerste wat je krijgt als je iets complex wil doen in een programmeertaal die je niet kent. Spaghetti. Dan heb ik wat zitten spelen met functies en subroutines. Ondertussen heb ik er enkele geschreven die het uitvoeren van queries op een database vergemakkelijken. Dat betekent dat ik voor een tiental queries, hooguit 1 of 2 lijntjes nodig heb. Nu ben ik zo’n beetje alles aan het uitkuisen in mijn code. Het ziet er al een pak overzichtelijker uit. Ik zou natuurlijk object-oriented kunnen gaan, maar écht veel tijd om een geëlaboreerd model daarvoor op te stellen heb ik niet. Ik zal al blij zijn als ik alles op een propere manier aan de klap kan krijgen.

Formuliervalidatie blijkt echter problematisch. Zeker als het formulier uit tig velden bestaat die waarvan de inhoud aan een pleiade aan condities moet voldoen. En dan zwijg ik nog over de beveiliging. Hmz.

13 replies

  • Tja, validatie van formulieren met het Struts-framework (Java) is vrij makkelijk. Daarbij kan je in een XML document aangeven welke velden van je form moeten gevalideerd worden en volgens welke regels. In een andere XML document geef je dan aan naar welke pagina er moet doorverwezen worden indien de invoer niet correct was. Het framework genereerd ook de foutboodschap wat er niet correct was, rechtstreeks op je HTML-pagina. Met J2EE werk je dan ook nog volledig taalonafhankelijk, vermits je in je JSP’s een symbolische link aangeeft voor de te tonen tekst. Die symbolische link is terug te vinden in verschillende bestanden voor elke te gebruiken taal. En nog iets Matthias, het is eigenlijk volledig tegen de regels in van de 3-lagen architectuur om vanuit je view-layer(ASP) rechtstreeks de database(data-layer) aan te spreken. Enfin, tot zover mijn promotie voor J2EE. Ik vermoed trouwens wel dat er voor ASP.NET ook wel een mogelijkheid zal bestaan voor validatie van forms en voor het scheiden van je layers. Het is immers niet nodig bij kleine toepassingen om de layers te scheiden (kost je immers meer tijd), maar als de projecten eenmaal groter beginnen worden, zal niemand er nog aan uit kunnen.

  • Formulier validatie doe je toch gewoon door vbscript in te bouwen, op de client side, of zoals ik eens gedaan heb aangezien je toch met een database bezig bent vermoed ik dat de velden in de database gelijk zullen noemen aan de velden in je formulier

    je roept de namen van de velden op uit je database en creeert met asp
    vbscript in je pagina

    als je vb script in je pagina zet en dan de broncode bekijkt in html zal je zien dat elke validatie per veld gelijk opgebouwd is en je dit kan oplossen met een lus als je enkel de namen van de velden in je formulier bv met asp kan laden uit je database

    Je creeert dan in asp door middel van een lus en response.write broncode van uw html waar je dan mis 1 keer wat denkwerk met gemak 100 velden kan valideren met hoogstens 10 lijnen. Zo heb ik het toch opgelost ooit eens..

    JA sorry uitleg kan wat verwarrend zijn

  • Formulier validatie doe je toch gewoon door vbscript in te bouwen, op de client side

    owla, en hoe zit het met je veiligheid als ik, als client, geen scripts toelaat? wordt dan gelijk welke query rechtstreeks uitgevoerd, zonder enige controle? Dan kun je evengoed je DB pass en username open en bloot geven…

    NB: ik heb wel geen ervaring met ASP, maar wel met PHP en daar is het absoluuuut not-done om bv. je form met javascript te valideren…

  • ja das wel juist als ge zo denkt 🙂 maja ge moet het afwegen he hoe ver ge gaat ofwel doet ge alles aan server-side en belast ge wel uw servers maar het is idd wel de oplossing om dingen zoals bij u tegen te gaan 😉 of ge verplicht dat vb script geaccepteerd wordt 🙂 tzijn afwegingen die ge zoveel moet maken he op internet. Met validatie in asp zijt ge dan wel zeker dat alle resultaten gecovered worden 🙂

  • “belasting van de servers” mag NOOIT een argument zijn om beveiliging achterwege te laten!

    En een check om te zien of alles wel een geldige string is, of ervoor zorgen dat je geen SQL-injection hebt, zijn nu niet echt de belastende processen hé…

    man, zoiets zou ik zelfs nooit overwegen, is dat niet les 1 in (internet-)beveiliging: vertrouw nooit de input van je gebruikers?

  • Matthias

    20 januari 2006 at 1:20 am

    Stimmt. Ik heb vanmiddag nog zelfs bezig geweest met checks op de input te balanceren. Ik doe dat allemaal serverside. En een SQL injection hoeft niet eens zo heel erg moeilijk te zijn. Zo heb ik zelf willen merken.

    Dergelijke checks zijn uiteindelijk niet zo super belastend voor een server. Het is niet dat ik met een loop een 100.000 tal inputs moet checken of zo.

    Wat zwaarder doorweegt is het aantal queries dat je maakt, en de aard van de queries. Zo kan je eenvoudig een SELECT statement maken, de inhoud dumpen in een array en dan met count (of in ASP UBound) het aantal records tellen. Of je doet dat met een while of do-until lus waar bij je een sentinel gebruikt die telkens eentje verhoogt tot EOF. Beter is het om gewoon gebruik ge maken van de COUNT(*) functie in SQL. Die werkt immers een pak performanter en een deel van de load haal je zo uit je ASP/PHP/… script.

    Verder heeft Bart wel gelijk. Een 3-TIER architectuur biedt niet anders dan voordelen. Maar er zijn verschillende redenen waarom ik het zo net niet aanpak:

    1. Ik ben géén professionele programmeur.
    2. Dat ontwikkelen en uitbalanceren kost tijd. Tijd die er helemaal niet is.
    3. De webinterface is in se een Q&D oplossing ter vervanging van een MS Access interface.
    4. De doelstellingen van het spul dat ik in elkaar zet zijn juist zéér beperkt.
    5. De omgeving waarin ik ontwikkel is niet écht flexibel te noemen. Ik kan zelfs geeneens POST variabelen laten passeren via mijn scripts. Enkel de GET methode werkt. Go figure! Ik ben al blij dat ik überhaupt aan de database geraak!!

  • waarom gebruik je feitelijk ASP en geen PHP? PHP kan toch via een ODBC-driver bij een Access MDB?

    Er bestaan daar iig genoeg tutorials voor, bv http://www.zend.com/zend/tut/odbc.php?article=odbc&kind=t&id=5062&open=1&anc=0&view=1

  • Matthias

    20 januari 2006 at 9:17 am

    wel,

    ’t is voor het werk dat ik dit doe. En ik ben gebonden aan de omgeving waarbinnen de applicatie moet draaien: een IIS server met ASP op en een MS SQL backend.

    Had ik gekund, ik zou zo overgeschakeld zijn op PHP.

  • Tip: gebruik javascript. Ook serverside, en in Javascript programmeren werkt voor mij meestal iets vlotter dan dat gedrogt van een VBScript. Je kan de twee zelfs mixen! Het voordeel van JScript is dat je objecten kan maken (zoals bij client side Javascript) en dat maakt de encapsulatie iets properder.

    Hoe?

    vanbovenaan de pagina en that’s it. wil je dan toch nog VBScript gebruiken, kan een

    wel helpen. Je kan functies oproepen vanuit JScript die in VBScript zijn gedefineerd, én omgekeerd ook.

  • Nog iets: gebruik clientside cursors voor de DB:

    objConn.CursorLocation = adUseClient

    Als je dan de connectie sluit nadat je de recordset hebt binnengekregen (maar voor je hem begint te doorlopen), krijg je disconnected recordset. De connectie met de DB is er niet meer (en dus minder belastend).

    Een bijkomend voordeel is dat de RecordCount property op de recordset dan ingevuld is (ipv -1) dus no need om een extra SELECT COUNT(*) te doen. 😉

  • of doe gewoon een getRows() van de recordset dan heb je een array

  • Matthias

    20 januari 2006 at 5:41 pm

    thx!!!

    Ik zat al te spelen met de RecordCount property maar die ik kreeg ik niet direct aan de klap… 🙂

  • Matthias

    20 januari 2006 at 5:44 pm

    VBScript laat nochtans ook OOP toe heb ik zo de indruk.

    Momenteel heb ik een paar klassen opgesteld en werk ik nu met een paar objecten die refereren aan het datamodel. Alles ziet er veel beter uit. Om nog maar te zwijgen van de voordelen.

Commentaar is gesloten