Alternatief voor een <select>

[orf]

In ons CMS maken we veelvuldig gebruik van een <select> om relaties aan te geven. Je kiest een categorie bij een product met een select, etc.

Die selects worden dynamisch (ajax) geupdate wanneer je iets wijzigt in bijvoorbeeld een andere select, of iets dergelijks.

Allemaal prima, totdat je te maken krijgt met onhandelbare aantallen. Een select met 3000 opties is voor de gebruiker niet makkelijk meer te gebruiken; de pagina laadt lang, ajax requests doen er veel te lang over om nog een beetje fijn te kunnen werken in het CMS.

Wat zou een goed alternatief zijn voor een select? Een suggestfield hebben we in ons CMS, maar een suggestfield is een redelijk vrij veld; ik wil niet een hoofdcategorie in kunnen typen die niet bestaat. Ik wil het id (Primary key) van het record hebben, iets waar je bij een select zeker van kunt zijn. Daarnaast is een select makkelijk met onchange acties e.d. en weet je bij een suggestfield niet exact wanneer de onchange uitgevoerd zou moeten worden. Hebben mensen hier wel eens gedacht aan alternatieven? Misschien ben je wel eens tegen hetzelfde probleem aangelopen.

Bedankt vast!

[Janoz]

Het suggestveld is een optie, maar kijk of je het kunt gebruiken om een selectie in je select te maken. Wat je ook zou kunnen doen is de grote lijsten te verdelen in hoofdgroepen en er vervolgens een extra select tussen te zetten. Je moet dan wel twee keer een keuze maken, maar de lijsten zijn veel kleiner.

[JKVA]

Als je met AJAX overweg kunt, is het denk ik ook geen probleem om zelf een component te maken die data van de server ophaalt (doe je nu ook al) en dat toont in iets anders dan een <SELECT>, bijvoorbeeld een div met een tabel erin. Die open je met een knopje en het tekstveld zelf laat je readonly.

Validaties van ingevoerde waarden moet je op de server ook gewoon nog een keer doen. Dat moet sowieso voor security en data integriteit en zo, maar dat is voor een dergelijk component ook gemakkelijk te doen. Gewoon nog een keer de lijst ophalen en kijken of de ingevoerde waarde voorkomt.

Deze opzet maakt het zelfs mogelijk om binnen je component sorteer- en zoekfunctionaliteit in te bouwen. Dat maakt het vrij veelzijdig.

Dergelijke componenten worden vaak lookups genoemd omdat ze bedoeld zijn om een waarde op te zoeken. En een AJAX implementatie is in zulke gevallen heel handig, onder andere omdat de rest van je form gevuld blijft.

[Verwijderd]

ik heb zelf ook een autocomplete gemaakt. Ik heb de http://www.funda.nl implementatie als voorbeeld gebruikt
^^
waarschijnlijk nutteloze ommerking als ik de TS lees

[ Voor 22% gewijzigd door Verwijderd op 18-01-2007 12:46 ]

[André]

Wat Janoz zegt lijkt me de beste oplossing: een select van 2000 opties kun je splitsen in 2 selects van ongeveer 45 opties

[Cartman!]

Kun je geen filtertool maken die op meerdere onderdelen kan filteren ipv 1 suggestieveld?
Voor een soort klantensysteem kan je bijv. zoeken op Voornaam/Achternaam/Bedrijf
die dingen combineer je met elkaar tot 1 query en dan blijven er weinig results over.

[WormLord]

Wat we hier wel eens doen in zo'n situatie is een zoek-scherm gebruiken.
Met een knop naast het veld ga je dan naar dat zoek-scherm (in een pop-up). En als er dan iets gevonden en gekozen is, dan word er met javascript informatie in het originele formulier geschreven (zoals een id in een verborgen veld en een tekst in het veld naast de knop).