Submit formulier in Ajax.Request

[Life]

Na het hele internet afgestruimd te zijn, heb ik maar besloten mijn probleem hier voor te leggen. Ik ben bezig met een loginsysteem. Nu wil ik dit loginsysteem in 1e instantie via AJAX (prototype framework) controleren op juistheid. Als de gebruikersnaam/wachtwoord niet overeenkomen, krijgt de gebruiker in een foutmelding via Ajax.request (ofwel, geen pagina refresh nodig).

Dit alles gaat perfect, en levert geen problemen op. Het probleem echter, is dat bij een succesvolle login, ik de cookies moet plaatsen. Hiervoor heb ik een volledige pagina refresh nodig, je kan immers geen cookies plaatsen binnen een ajax.request ivm geparste HTML).

Nu probeer ik dus, als de login correct is, het formulier te submitten. Alleen herkent deze de functie .submit(); niet.

Code van formulier

code:

<input type='submit' value='Invoeren' onClick="checkForm('formid', 'login_check'); formFocus = false; return false;" name='submit' />

Code van aangeroepen functie in het formulier

code:

function checkForm(formID, ajax_url)
{
    var formName = formID;
    var forward_url = '../ajax/' + ajax_url + '.php';
    
    $('notice').innerHTML = '<img title=\"Bezig met laden...\" src=\"../img/loader.gif\" /> Bezig met laden...';
    
    new Ajax.Updater('notice', forward_url, 
    {
            asynchronous:true, 
            evalScripts:true, 
            parameters:Form.serialize(formName)
    });
}

De bedoeling is dus dat het formulier binnen de gerequeste ajaxfile (in dit geval: login_check.php) gesubmit wordt.

Code in login_check.php na succesvolle validatie

code:

if ($errorFound == false)
{
    //Forward
    ?>
    <script type='text/javascript'>
    $('formid').submit();
    </script>
    <?
}

Het vreemde is, is dat als ik bv $('formid').reset(); of iets anders invoer, het wel opgepakt wordt door het formulier en gewoon werkt. Hij wil gewoon niet submitten. Is het onmogelijk wat ik probeer te bewerkstelligen of pak ik het helemaal verkeerd aan?

[Bosmonster]

Ik weet niet hoe het in prototype werkt, maar moet je niet eerst het specifieke element uit de verzameling halen ($ geeft altijd een verzameling terug volgens mij).

Bijvoorbeeld:

JavaScript:

$('form#formid')[0].submit();

// of in jQuery werkt ook:
$('form#formid').get(0).submit();

Edit: verder neem ik ook even aan dat alleen 'formid' geen typfout was en dat je daar het # vergeten was

[ Voor 17% gewijzigd door Bosmonster op 24-07-2008 23:14 ]

[crisp]

HTML:

<input name='submit'>

haal die name='submit' daar eens weg of noem die anders

Overigens kan je met javascript ook cookies zetten

[ Voor 21% gewijzigd door crisp op 24-07-2008 23:21 ]

[Life]

Bosmonster schreef op donderdag 24 juli 2008 @ 23:10:
Ik weet niet hoe het in prototype werkt, maar moet je niet eerst het specifieke element uit de verzameling halen ($ geeft altijd een verzameling terug volgens mij).

Bijvoorbeeld:

JavaScript:

$('form#formid')[0].submit();

// of in jQuery werkt ook:
$('form#formid').get(0).submit();

Edit: verder neem ik ook even aan dat alleen 'formid' geen typfout was en dat je daar het # vergeten was

Via prototype kan je alle elementen met een ID aanroepen via $('id_hier').
De inhoud van textfields roep ik ook op via $('textfield').value bv. Hier ligt het dus niet aan

[Life]

crisp schreef op donderdag 24 juli 2008 @ 23:20:

HTML:

<input name='submit'>

haal die name='submit' daar eens weg of noem die anders

Overigens kan je met javascript ook cookies zetten

Geweldig, dit was het probleem! Het werkt nu Ik snap alleen nog niet dat door een name='submit' het niet meer werkt.

[crisp]

Bosmonster schreef op donderdag 24 juli 2008 @ 23:10:
Ik weet niet hoe het in prototype werkt, maar moet je niet eerst het specifieke element uit de verzameling halen ($ geeft altijd een verzameling terug volgens mij).

$ heeft niet in elk framework dezelfde betekenis/werking (leuk hè, het lijken net browsers die javascript frameworks )

[Bosmonster]

Life schreef op donderdag 24 juli 2008 @ 23:22:
[...]

Via prototype kan je alle elementen met een ID aanroepen via $('id_hier').
De inhoud van textfields roep ik ook op via $('textfield').value bv. Hier ligt het dus niet aan

Een van de rarigheidjes van Prototype. Gezien de CSS-syntax die verder toegepast wordt in de selectors zou dat natuurlijk gewoon $('#id_hier') moeten zijn, anders kom ik in de knoop als ik gewoon alle divs wil hebben bijvoorbeeld en er een element is met de id 'div' Maar daar zullen ze wel weer een andere inconsistente oplossing voor bedacht hebben.

crisp schreef op donderdag 24 juli 2008 @ 23:27:
[...]

$ heeft niet in elk framework dezelfde betekenis/werking (leuk hè, het lijken net browsers die javascript frameworks )

jQuery is daar in ieder geval consistent in. $ werkt altijd met CSS-selectors en geeft altijd een collectie terug. Zo weet je ook altijd waar je aan toe bent imho.

Edit: prototype heeft daar een hele losse functie voor bedacht zie ik $$.. njah, beetje overbodig als je het mij vraagt. Een functie die specifiek iets doet en eentje die dat ook kan, maar de rest ook $('id') is dan hetzelfde als $$('#id'). Zal wel met backwardscompatibility te maken hebben dan.

/end prototype bash

* Bosmonster hugs jQuery

[ Voor 35% gewijzigd door Bosmonster op 24-07-2008 23:35 ]

[Noork]

Life schreef op donderdag 24 juli 2008 @ 22:42:
Het probleem echter, is dat bij een succesvolle login, ik de cookies moet plaatsen. Hiervoor heb ik een volledige pagina refresh nodig, je kan immers geen cookies plaatsen binnen een ajax.request ivm geparste HTML).

Kun je dat niet gewoon op een of andere manier werkend krijgen? Ik heb zelf een reageer-scriptje gemaakt voor een weblog op basis van Ajax (met behulp van Jquery forms welliswaar). Ik kan met een Javascript functie (post submit functie) gewoon createCookie() gebruiken. Wellicht is er ook zoiets voor Prototype.

[crisp]

Life schreef op donderdag 24 juli 2008 @ 23:25:
[...]


Geweldig, dit was het probleem! Het werkt nu Ik snap alleen nog niet dat door een name='submit' het niet meer werkt.

Simpel: elk input-element binnen een form met een name-attribuut wordt ook een property van het form-element, je kan 'm immers middels formElement.name benaderen (netter is via de elements collectie though). Je kan dus wel raden wat er gebeurd met form.submit() als je een input-element met name="submit" gebruikt

Bosmonster schreef op donderdag 24 juli 2008 @ 23:27:
[...]
jQuery is daar in ieder geval consistent in. $ werkt altijd met CSS-selectors en geeft altijd een collectie terug. Zo weet je ook altijd waar je aan toe bent imho.

jQuery was niet het eerste framework dat de (imo ranzige) $ shortcut gebruikte, maar naar mijn weten wel de eerste die hem met CSS selectors liet werken (waar prototype o.a. $$() voor heeft) en daarmee afweek van andere frameworks.

Maar on the bright side: over een paar jaar kunnen we $(), $$(), getElementsBySelector() etcetera allemaal vergeten en kunnen we overal native querySelector gebruiken

[Bosmonster]

crisp schreef op donderdag 24 juli 2008 @ 23:38:
[...]

jQuery was niet het eerste framework dat de (imo ranzige) $ shortcut gebruikte, maar naar mijn weten wel de eerste die hem met CSS selectors liet werken (waar prototype o.a. $$() voor heeft) en daarmee afweek van andere frameworks.

Maar on the bright side: over een paar jaar kunnen we $(), $$(), getElementsBySelector() etcetera allemaal vergeten en kunnen we overal native querySelector gebruiken

De $ var is optioneel in jQuery en je kunt hem ook nu al querySelector noemen hoor als je dat zou willen

Overigens is het gebruik van de $-variabele ook ongeveer de enige overeenkomst verder tussen de prototype-based libraries (scriptaculous en in zekere zin ook mootools) en jQuery.

[crisp]

Bosmonster schreef op donderdag 24 juli 2008 @ 23:46:
[...]


De $ var is optioneel in jQuery en je kunt hem ook nu al querySelector noemen hoor als je dat zou willen

Overigens is het gebruik van de $-variabele ook ongeveer de enige overeenkomst verder tussen de prototype-based libraries (scriptaculous, mootools) en jQuery.

De andere overeenkomst is dat ik ze allemaal redelijk goed ken qua werking maar ze geen van allen wens te gebruiken

[Bosmonster]

crisp schreef op donderdag 24 juli 2008 @ 23:50:
[...]

De andere overeenkomst is dat ik ze allemaal redelijk goed ken qua werking maar ze geen van allen wens te gebruiken

Als je de tijd hebt om componenten compleet zelf te bouwen, en die extra efficiency die daaruit voortkomt ook echt uitmaakt, zoals bij T.NET, dan kan ik je daar wel gelijk in geven.

Maar in een zakelijke omgeving waar ieder uur er een teveel is zijn de libraries bijna onmisbaar als je enige dynamiek aan je frontend wil toevoegen zonder elke keer naar Flash te moeten grijpen. Het minimale beetje overhead van de library code is dan verwaarloosbaar.

[ Voor 5% gewijzigd door Bosmonster op 24-07-2008 23:53 ]

[Verwijderd]

Bosmonster schreef op donderdag 24 juli 2008 @ 23:27:
jQuery is daar in ieder geval consistent in. $ werkt altijd met CSS-selectors en geeft altijd een collectie terug. Zo weet je ook altijd waar je aan toe bent imho.

$ in jQuery kun je ook een HTML-string meegeven (creeert een element) of een DOM element referentie (creeert een jQuery object wrapper voor dat element).

[crisp]

Verwijderd schreef op vrijdag 25 juli 2008 @ 09:18:
[...]

$ in jQuery kun je ook een HTML-string meegeven (creeert een element) of een DOM element referentie (creeert een jQuery object wrapper voor dat element).

Ja, het is echt een soort Frankenstein in jQuery

[--MeAngry--]

Ben ik de enige trouwens die de oplossing van de TS vrij ranzig vindt?

Persoonlijk had ik z'n formcontrole in de onsubmit geplaatst en daarin true of false terug gegeven. Dan heb je in ieder geval al die ranzige innerHTML niet meer nodig.

[Bosmonster]

Verwijderd schreef op vrijdag 25 juli 2008 @ 09:18:
[...]

$ in jQuery kun je ook een HTML-string meegeven (creeert een element) of een DOM element referentie (creeert een jQuery object wrapper voor dat element).

Je kan er nog wel meer mee (functie-ref als shortcut voor de documentready bijvoorbeeld), maar ik doelde even op de selectors.

--MeAngry-- schreef op vrijdag 25 juli 2008 @ 09:29:
Ben ik de enige trouwens die de oplossing van de TS vrij ranzig vindt?

Persoonlijk had ik z'n formcontrole in de onsubmit geplaatst en daarin true of false terug gegeven. Dan heb je in ieder geval al die ranzige innerHTML niet meer nodig.

Ow ja wacht, het topic ging over formvalidatie

[ Voor 34% gewijzigd door Bosmonster op 25-07-2008 09:32 ]

[crisp]

formcontrole moet altijd in een onsubmit, en referencies geef je het beste mee met het 'this' keyword. Maar ik geloof dat ik zelf de moed al opgegeven heb met het noemen van dat soort zaken...

[Kiphaas7]

crisp schreef op vrijdag 25 juli 2008 @ 09:32:
formcontrole moet altijd in een onsubmit, en referencies geef je het beste mee met het 'this' keyword. Maar ik geloof dat ik zelf de moed al opgegeven heb met het noemen van dat soort zaken...

Ik ruik een opleving van de FAQ?

[Life]

Zoals gesuggereerd heb ik nu de formvalidatie via submit gedaan, en gelijk op een wat nettere manier:

code:

Event.observe(window, 'load', function() {
  Event.observe('formid', 'submit', function(event) { 
        checkForm('formid', 'login_check'); formFocus = false; return false; 
    });
});

Het liefst zou ik inderdaad met een true/false werken en daarop submitten. Het enige probleem is, is dat ik ook PHP/MySQL checks in mijn formvalidatie nodig heb. Bijvoorbeeld als de username al in gebruik is.

De acties die ik onderga, als er een fout gevonden is, zijn:

• Kleur van textfield veranderen in groen of rood
• De foutmelding weergeven achter het textfield
• De focus() op de 1e fout zetten

Zover ik weet ben ik dus wel geforceerd om het via een php bestand, dankzij Ajax.request, te controleren. Is er ook een manier om geen Ajax.request te gebruiken en alles via event.observe te valideren, inclusief PHP/MySQL checks?

[ Voor 24% gewijzigd door Life op 25-07-2008 19:14 ]

[JKVA]

Life schreef op vrijdag 25 juli 2008 @ 19:00:
Zoals gesuggereerd heb ik nu de formvalidatie via submit gedaan, en gelijk op een wat nettere manier:

code:

Event.observe(window, 'load', function() {
  Event.observe('formid', 'submit', function(event) { 
        checkForm('formid', 'login_check'); formFocus = false; return false; 
    });
});

Ehm, ik meen me te herinneren dat return false niet werkt als je met Event.observe werkt. Volgens mij moet je een call naar event.stop() doen om het standaard form gedrag te voorkomen.

Het liefst zou ik inderdaad met een true/false werken en daarop submitten. Het enige probleem is, is dat ik ook PHP/MySQL checks in mijn formvalidatie nodig heb. Bijvoorbeeld als de username al in gebruik is.

De acties die ik onderga, als er een fout gevonden is, zijn:

• Kleur van textfield veranderen in groen of rood
• De foutmelding weergeven achter het textfield
• De focus() op de 1e fout zetten

Zover ik weet ben ik dus wel geforceerd om het via een php bestand, dankzij Ajax.request, te controleren. Is er ook een manier om geen Ajax.request te gebruiken en alles via event.observe te valideren, inclusief PHP/MySQL checks?

Zolang je je foutmeldingen qua taal/layout hetzelfde laat, kun je die dingen volgens mij prima met PHP checken en de rest met JavaScript/AJAX. Je haalt jezelf redelijk wat op de hals als je alles met met AJAX gaat bouwen.

[--MeAngry--]

Als je perse een formvalidatie wil doen voor de refresh kun je dat het beste middels PHP doen, wat namelijk als een gebruiker z'n Javascript uitschakelt? Dan wordt er geen controle meer gedaan.

Wat je dus eigenlijk doet als je toch perse controle wil voordat er een refresh wordt gedaan:

• onsubmit afvangen met een Ajaxcall naar je PHP-script met formvalidatie
• Bij een juiste validatie true returnen en de onsubmit z'n weg laten vervolgen
• Deze gegevens posten naar hetzelfde script waar wederom de controle wordt uitgevoerd, maar dit keer ga je ook iets met de gegevens doen.

Als je dat slim doet hoef je dan maar 1 script te schrijven voor de controle (in PHP). Andere oplossingen doen eerst validatie middels JavaScript, en vervolgens nogmaals in PHP, daarmee maak je het voor jezelf wel moeilijk omdat je 2 scripts met dezelfde functionaliteit moet onderhouden.

Dus opzich is je huidige manier van aanpakken prima, nu hoef je het alleen nog maar wat netter uit te werken.