De waarde die ik daarin invul word direct zichtbaar gemaakt met dit.:
<script>
$(document).ready(function(){
$("#myInput").on("input", function(){
// Print entered value in a div box
$("#result").text($(this).val());
});
});
</script>
Ik heb nu een 4 cellen naast elkaar, zie onderstaande code.:
Nu vraag ik jullie hulp hierbij omdat ik het niet weet en krijg.
Tis de bedoeling dat ik die 4 regels terug breng naar 1 regel, maar dat hij zich aanpast op het geen dat ingevuld word in de input box.
Dus type ik 1 in moet direct 1 cell getoond worden, type ik 3 moet direct 3 cellen getoond worden, uiteraard zonder refresh page of submit button.
Is dit mogelijk? Zou mij iemand kunnen helpen hiermee?
De reden is dat je dan geen verdere overhead nodig hebt in je scripts, het wordt een onnodig groot verhaal qua bandbreedte van je inet-verbinding. In sommige gevallen zoals in een confirmbox zul je weer een plugin toe moeten voegen wat in principe niet nodig is want jquery heeft native-js standaard ingebouwd.
JQuery heeft helemaal niets ingebouwd maar is een bibliotheek met handige javascript functies die je het leven makkelijk maken. En oh ja er moet een bestandje extra worden ingeladen. Dat klopt en ja je kunt zonder JQuery. Maar dat bestandje wordt door de browsers gecached dus dat scheelt weer enorm. En in een aantal gevallen zorgt JQuery er wel voor dat de functies via wat zijsprongen wel in een breed scala aan browsers goed werkt wat op zich dus ook wel weer een voordeel is.
Waar Ariën volgens mij op doelt is dat er in het code fragment op de ene plek wel gebruik gemaakt wordt van JQuery en op de andere plek niet. Je laadt dan dus JQuery in en maakt er vervolgens geen optimaal gebruik van. Ik zou dan zeggen doe of het één of het ander.
Ben er zelf geen fan van, maar als je van CDN's gebruik maakt voor jQuery, dan heb je potentieel al alles ingeladen van andere sites. En na het inladen wordt alles gecached, dus dit is vaak eenmalig. Daarnaast, bandbreedte, geheugen en CPU-snelheid zijn tegenwoordig minder een probleem. Is geen excuus om minder optimaal te programmeren, maar een kleine knieval doen om vervolgens te beschikken over een uitgebreide library lijkt mij de uitwisseling waard. Maar dan moet je er dus vervolgens wel (optimaal) gebruiken van maken inderdaad.
Ik ben een voorstander van alles zo simpel mogelijk houden, maar niet simpeler. Het inladen van een minimale set aan hulpstukken is dan de prijs die je betaalt. In het bovenstaande gebruik ik alleen de (minified!) jQuery library, verder niets.
NB vergeet ook niet dat jQuery cross browser compatibility hoog in het vaandel heeft. Als je iets in jQuery schrijft heb je dus ook enige garantie dat dit in verschillende browsers werkt. Dit mogelijk in tegenstelling tot "native" JavaScript.
Ik krijg de fout bij $MaterialCode$x maar doe ik $MaterialCode[$x] is het wel goed, echter die [] wil ik niet.
Is dit op te lossen?
Het is namelijk zo $MaterialCode$x komt 98 keer helaas , dus dacht een lusje te maken maar dat gaat dan niet zo?
echter die [] wil ik niet.
Het is namelijk zo $MaterialCode$x komt 98 keer helaas , dus dacht een lusje te maken maar dat gaat dan niet zo?
Zoals ik al eerder aangaf, op het moment dat je zulke naamgeving hebt wordt het hoog tijd om je aanpak te herzien. Dit is ook afleidbare informatie. Blijkbaar is de volgorde relevant, dat kan, maar dan hoef je nog steeds niet zo alles apart te nummeren. Je kunt specifieke velden indexeren als dit er echt toe doet:
<input type="text" name="searchBox[88]">
Of gewoon open laten als dit een aaneengesloten rij moet zijn (en blijven) als het volgnummer niet belangrijk is, maar de volgorde wel:
<input type="text" name="searchBox[]">
Ik vermoed dat je dit graag zo wilt houden omdat je vervolgcode ook zo in elkaar steekt, maar dit zou ik echt aanpassen. Dat kost dan misschien wat extra werk, maar dit levert een veel schonere oplossing op dan het introduceren van 98+ verschillende variabelen en wie weet wat voor andere kunstgrepen hiervoor nodig zijn.
Ik zou haast willen zeggen dat wat jij doet (zeer) ongebruikelijk is. Ik vind het dan ook altijd opmerkelijk dat iemand op grond van reacties gemotiveerd wordt om deze aanpak voort te zetten. Dit is voortborduren op een "slecht" ontwerp.
Sure, het zal wel werken. Maar het leest moeilijk(er), het is ingewikkelder om te debuggen en dit alles maakt het gewoon moeilijker in het gebruik met onnodig tijdsverlies als gevolg. Maak alles zo simpel mogelijk. Op het moment dat je met databases en formulieren bezig bent zouden arrays toch ook wel moeten lukken?
Op het moment dat een veldnaam meer dan één keer gebruikt wordt dan zou je eigenlijk al meteen aan arrays moeten denken. Ook vanwege schaalbaarheid, flexibiliteit, foutgevoeligheid et cetera.
NB: je gebruikt in de verwerking in je for-loop het "magische getal" 25. Maar dit zou niet nodig hoeven zijn, en waarom zou dit vast moeten liggen? Ik dacht juist dat dit flexibel diende te zijn? Je oorspronkelijke bericht gaf in ieder geval die indruk, dit zou slechts een bovengrens moeten zijn? De enige plek waar die begrenzing dus eigenlijk hoeft te zitten is in het formulier zelf? Het nadeel van deze aanpak is ook dat je mogelijk op meerdere plaatsen dit "magische getal" aan moet passen. Hard coding is nooit een goede zaak...
1 vraagje nog.
Wat adviseren jullie het beste.
1 extreem grote database of allemaal kleintjes?
Ik denk zelf allemaal kleintjes maar zou graag jullie advies horen.
Mijn vermoeden is met die grote dat het dan allemaal on overzichtelijk word en lang nodig zal hebben met laden.
Eén database prima. Ik neem hierbij aan dat het niet gaat om een SaaS-product.
Als deze database goed is opgebouwd (lees: genormaliseerd) kan deze prima grote volumes aan data aan. Computers zijn geen oude abacussen meer, maar snelle machines die berekening in no-time kunnen doen. Dus waarom denk je dat het met grote hoeveelheden data traag zou zijn?
Ik heb wel eens een database van enkele gigabytes gehad, en daar kon ik prima queries op uitvoeren, en binnen de juiste vlotte tijd resultaten mee binnenhalen. Natuurlijk waren wat indexes juist een must, en goed afgestemde queries voor met name bij het gebruik van relationele koppelingen.
