Het gebruik van de maxlength attribute

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Guido  -

Guido -

03/04/2019 17:21:31
Quote Anchor link
Hallo,

Ik heb een eigen contactformulier en om gebruikers geen overbodige info te laten invoeren, maak ik voor mijn inputs gebruik van de maxlength attribute. Alles wordt ook in een database opgeslagen, dat is mede de reden van deze restrictie. Ik weet overigens dat bots dit omzeilen.

Voor een wachtwoord- of datumveld zou een maxlength handig kunnen zijn, maar ik vraag me nu af of het voor de overige inputs überhaupt zinvol is.. ik twijfel nu. Graag jullie mening?

Groeten, Guido
 
PHP hulp

PHP hulp

08/05/2024 01:29:03
 
Thomas van den Heuvel

Thomas van den Heuvel

03/04/2019 17:43:16
Quote Anchor link
Het zou niet uit moeten maken hoe lang een wachtwoord is, je slaat immers enkel de hash op toch? If anything, een wachtwoord zou een minimum lengte moeten hebben.

Een datumveld laat je iemand idealiter niet handmatig invullen, ik zou dan gebruik maken van een datepicker ofzo. Als je niet wilt dat iemand fouten kan maken, geef hem/haar daartoe dan ook niet de gelegenheid.

maxlength gaat volgens mij, correct me if I'm wrong, over het aantal karakters, maar een karakter kan bestaan uit meerdere bytes. Ik zou dus theoretisch karakters in kunnen voeren die 4x de toegestane (geheugen)lengte hebben. En dit kan dan weer van invloed zijn hoeveel informatie je kwijt kunt in een database-kolom.

En dan tellen browsers ook verschillend. Dit artikel heb ik snel gevonden, verder niet gecontroleerd, en is inmiddels wat gedateerd, wellicht is dit inmiddels al gerepareerd/achterhaald.

Voorlopige conclusie: met maxlength kun je een indicatie geven hoe lang invoer mag zijn, maar hoe lang de invoer dan daadwerkelijk is kan (sterk) variëren en mogelijk de maxlength overstijgen.

Ik zou dit ook per invoerveld bekijken. Als er logische restricties zijn (couponcode, getal tussen 0 en 100 et cetera) dan is een maxlength zeker op zijn plaats.
Gewijzigd op 03/04/2019 17:43:43 door Thomas van den Heuvel
 
Guido  -

Guido -

03/04/2019 18:27:51
Quote Anchor link
Hoi Thomas,

Bedankt voor je reactie.

Ik heb reguliere inputs, zoals naam, e-mailadres, onderwerp, etc.
Jaren geleden had ik het idee dat het geen kwaad kon om wat restricties te geven voor deze inputs, maar ondertussen twijfel ik zelf dus ook erg aan het nut ervan, in deze gevallen dan.
Voor datum gebruik ik idd een datepicker, maar dacht dat dit icm maxlength=10 (dd-mm-jaar) geen kwaad kan.

Guido
 
Thomas van den Heuvel

Thomas van den Heuvel

03/04/2019 19:35:16
Quote Anchor link
Guido - op 03/04/2019 18:27:51:
Voor datum gebruik ik idd een datepicker, maar dacht dat dit icm maxlength=10 (dd-mm-jaar) geen kwaad kan.

Meh, dat (vaste) patroon impliceert ook een (vaste) lengte. Ik zou dan eerder kijken of het patroon voldoet. Ik hoop trouwens dat je het opslaat als yyyy-mm-dd, en niet als dd-mm-yyyy :).
 
Rob Doemaarwat

Rob Doemaarwat

03/04/2019 19:35:17
Quote Anchor link
Guido - op 03/04/2019 17:21:31:
Voor een wachtwoord- of datumveld zou een maxlength handig kunnen zijn, maar ik vraag me nu af of het voor de overige inputs überhaupt zinvol is.. ik twijfel nu. Graag jullie mening?


Huh, bedoel je dit nu andersom: "voor een wachtwoord- of datumveld GEEN maxlength"? Of bedoel je werkelijk dat je voor bijvoorbeeld een naam of e-mail veld de noodzaak van een maxlength niet ziet? Juist bij echt vrije velden (naam, adres, e-mail) is het handig om de gebruiker te laten weten hoeveel ruimte ie heeft. Zeker omdat in de huidige opmaak vaak alle velden even breed zijn (maar niet in de database).

En dan controleer je dit nog een keer server-side (voor de browser die verkeert telt, of voor de bot die je probeert te foppen). Pas als alles correct is sla je het op, en als het niet past geef je feedback en laat je het de gebruiker aanpassen (in plaats van maar gewoon de database de "rest" er af te laten trimmen).
 
Guido  -

Guido -

03/04/2019 19:48:06
Quote Anchor link
Foutje van mijn kant, wachtwoordveld is geen goed voorbeeld.. zou je idd beter minlength voor kunnen gebruiken (dank, Thomas). Maar voor datumveld wel, zodat gebruiker nooit meer dan de (in mijn voorbeeld) 10 karakters invoert, mocht de datepicker om wat voor reden dan ook niet werken. Even voor de duidelijkheid, validatie staat los van mijn vraag.

Rob, ik maak hieruit op dat je het dus wél zinvol vindt om een maxlength op "vrije velden" te zetten?

Guido
 
Rob Doemaarwat

Rob Doemaarwat

03/04/2019 22:50:09
Quote Anchor link
Ja. Ik vind het niet handig als brede velden van alles beloven en de gebruiker pas na een submit een foutmelding krijgt dat de invoer te lang is. Of helemaal geen foutmelding, maar slechts de helft van z'n invoer terug ziet.

Wat je hooguit nog zou kunnen doen is de maxlength weglaten, maar zelf via javascript een lengte check doen (en dan dus een melding of andere terugkoppeling als de invoer te lang wordt). Dat geeft de gebruiker de kans om toch even door te typen, en dan ergens anders (bijvoorbeeld aan het begin) te gaan schrappen (zoals Twitter dat bijvoorbeeld doet).
 
Guido  -

Guido -

05/04/2019 00:26:41
Quote Anchor link
Hallo,

Mijn hoofdreden is dat er niet (te) veel content (tekst) wordt gestuurd naar de DB, maar door de maxlength vang ik dat natuurlijk niet geheel af. Ik zou daarom een combinatie van een maxlength en mb_substr kunnen gebruiken. En dan een hele ruime waarde nemen zodat alleen extreme invoer afgevangen wordt. Dus dat de gemiddelde gebruiker er helemaal niets van merkt. Iedereen blij.. dacht ik zo. Idee?

Guido
 
Rob Doemaarwat

Rob Doemaarwat

05/04/2019 08:12:50
Quote Anchor link
En wat neem je dan "heel ruim", die mb_substr of die maxlength? En waarom^2: waarom zou je die twee laten verschillen? De limiet is de limiet. Daar kun je maar beter meteen duidelijk in zijn.
 
Ward van der Put
Moderator

Ward van der Put

05/04/2019 10:07:37
Quote Anchor link
Aandachtspunt lijkt me niet zozeer hoe de data wordt opgeslagen, maar vooral hoe die elders wordt gebruikt.

Er is weinig op tegen om tekst die je alleen zelf gebruikt op te slaan in een VARCHAR(255). Dat verandert wanneer je moet aanwerken tegen de API's en andere systemen van derden: dan kun je ineens aanlopen tegen limieten die uit de lucht lijken gegrepen, zoals 95 karakters voor een straatnaam en 24 karakters voor een plaatsnaam.
 
Guido  -

Guido -

10/04/2019 13:13:27
Quote Anchor link
Hallo,

Bedankt voor het meedenken.
Besloten om een ruime maxlength te gebruiken zodat er geen hele blokken tekst door gebruikers vh formulier gestuurd (kunnen) worden. Gebruik van mb_substr ga ik niet doen, kan bovendien tot verwarring leiden (afgekapte tekst). Wou dat in eerste instantie alleen gebruiken om content van bots af te kappen na een x aantal karakters.

Guido
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.