[Javascript & PHP] Array met checboxen op form

[ViNyL]

Ik heb een form met daarin een array van checkboxes:

HTML:

                    <td class="row2"><input name="apps[]" type="checkbox" value="STM" /> STM</td>
                    <td class="row3"><input name="apps[]" type="checkbox" value="Vila" /> Vila</td>
                    <td class="row4"><input name="apps[]" type="checkbox" value="Microsoft Visio" /> Microsoft Visio</td>

Omdat ik ze met PHP wil uitlezen heb ik ze als name gegeven:

HTML:

 name="apps[]"

Alleen nu wil ik met javascript een van deze checkboxes aanvinken als er een bepaalde keuze elders op mijn form gemaakt wordt.
Nu merk ik alleen dat javascript en php anders omgaan met een array.

Als ik namelijk deze javascript code uit voer als de tag name staat als hiervboven dan werkt het niet:

JavaScript:

document.edit.apps[1].checked = true;

Pas ik nu de tag van mijn checkboxen aan door ze allemaal dit mee te geven:

HTML:

name=apps

en voer ik de javascript code uit dan wordt de checkbox wel geselecteerd!

Toch wil ik de checkboxes met php uitlezen als het form geubmit wordt en ik wil ook de checkboxes met javascript aan kunnen spreken..

Is hier een oplossing voor zodat beide mogelijk is?

[SchizoDuckie]

Geef ze naast een name ook een id

of :

JavaScript:

document.getElementsByName("apps[]")[1].checked = true;

[ Voor 60% gewijzigd door SchizoDuckie op 10-01-2008 15:54 ]

[moozzuzz]

SchizoDuckie schreef op donderdag 10 januari 2008 @ 15:53:

JavaScript:

document.getElementsByName("apps[]")[1].checked = true;

Cool, ik heb me al suf bedacht hoe ik met "array"-namen kon werken in JS vs. forms (zonder een ID te moeten toekennen). Ik heb met name de (slechte/goede?) neiging om steeds array-variablen te posten naar de verwerkende scripts.

Zelf werk ik dan nooit met de apps[] vorm zoals de in de TS, want dat vind ik maar verwarrend voor de verwerking in PHP (vind het persoonlijk zelfs bad coding), maar wel apps[id], apps[title], ...

Als je dan de vorm document.edit.apps[id].checked zou proberen (of andere pogingen; ik ben al creatief geweest... ), protesteert JS heftig :^) Met de oplossing van SchizoDuckie wordt de drempel om aan formvalidation te doen (mijn goed voornemen van 2008) zo goed als helemaal weggenomen :^)

[SchizoDuckie]

moozzuzz schreef op vrijdag 11 januari 2008 @ 11:00:
[...]

Cool, ik heb me al suf bedacht hoe ik met "array"-namen kon werken in JS vs. forms (zonder een ID te moeten toekennen). Ik heb met name de (slechte/goede?) neiging om steeds array-variablen te posten naar de verwerkende scripts.

Zelf werk ik dan nooit met de apps[] vorm zoals de in de TS, want dat vind ik maar verwarrend voor de verwerking in PHP (vind het persoonlijk zelfs bad coding), maar wel apps[id], apps[title], ...

Als je dan de vorm document.edit.apps[id].checked zou proberen (of andere pogingen; ik ben al creatief geweest... ), protesteert JS heftig :^) Met de oplossing van SchizoDuckie wordt de drempel om aan formvalidation te doen (mijn goed voornemen van 2008) zo goed als helemaal weggenomen :^)

Hou je dan maar vast voor m'n mootools formvalidatie die ik binnenkort ga releasen Dan kan je dus dit doen:

JavaScript:

var formValidations = {
 '#ditismijnID' : { validation: 'number', mandatory: true}, // validate een input by ID
 '.formuliertje INPUT[type=text] ' : { validation: 'anything' }, // validate een input by css selector
 'pindakaas[2]' : validation: function() { return parseInt(this.value) > 25 } // validate input by name + custom validatie method
}

Nou alleen nog even de tijd vinden om het een en ander online te gooien

[crisp]

SchizoDuckie schreef op vrijdag 11 januari 2008 @ 16:54:
[...]


Hou je dan maar vast voor m'n mootools formvalidatie die ik binnenkort ga releasen Dan kan je dus dit doen:

JavaScript:

var formValidations = {
 '#ditismijnID' : { validation: 'number', mandatory: true}, // validate een input by ID
 '.formuliertje INPUT[type=text] ' : { validation: 'anything' }, // validate een input by css selector
 'pindakaas[2]' : validation: function() { return parseInt(this.value) > 25 } // validate input by name + custom validatie method
}

Nou alleen nog even de tijd vinden om het een en ander online te gooien

Leuk, maar waarom bouw je niet gewoon voort op Webforms 2? Dat wordt uiteindelijk de standaard (en er zijn al JS implementaties voor browsers die het niet native ondersteunen)

[ Voor 10% gewijzigd door crisp op 11-01-2008 17:00 ]

[SchizoDuckie]

crisp schreef op vrijdag 11 januari 2008 @ 16:57:
[...]

Leuk, maar waarom bouw je niet gewoon voort op Webforms 2? Dat wordt uiteindelijk de standaard (en er zijn al JS implementaties voor browsers die het niet native ondersteunen)

Sorry, maar ik ga niet inzetten op een spec die voorlopig toch niet native ondersteund gaat worden dan liever m'n eigen lightweight shit die ik helemaal kan customizen.

Overigens vind ik "dat wordt uiteindelijk de standaard" wel een bold statement voor iets wat de afgelopen 10 jaar niet verbeterd is...

[Verwijderd]

wf2 is behoorlijk mature iig, de stelling "dat wordt de standaard" is niet zo heel bold

zelf al eens een behoorlijk end zitten kleien in die richting: http://www.rikkertkoppes.com/thoughts/wf2/

moet het eigenlijk nog eens echt afmaken (de code is wat vies nog)

[ Voor 50% gewijzigd door Verwijderd op 11-01-2008 19:11 ]

[crisp]

WF2 is onderdeel van HTML5 en Opera biedt er al native support voor.

Het nadeel van een koppeling voor validation-behaviour op basis van selector-syntax is dat het behoorlijk breekbaar is (tenzij je puur en alleen een class of id-selector gebruikt) en het voegt semantisch gezien niets toe, wat bijvoorbeeld een 'required' attribuut op het element zelf wel doet.

[ Voor 68% gewijzigd door crisp op 11-01-2008 20:27 ]

[SchizoDuckie]

crisp schreef op vrijdag 11 januari 2008 @ 20:23:
WF2 is onderdeel van HTML5 en Opera biedt er al native support voor.

Sorry, maar i'm totally not impressed. Een niche browser met 0.2% coverage en het is onderdeel van een future spec. Voorlopig gebruikt 99% van de tuinders en omliggende vakgebieden (doelgroep van de organisatie waar ik momenteel werk) nog IE 5.5+. Ik snap de filosofie erachter, maar bruikbaar is het idee echt niet de komende paar jaren.

Het nadeel van een koppeling voor validation-behaviour op basis van selector-syntax is dat het behoorlijk breekbaar is (tenzij je puur en alleen een class of id-selector gebruikt) en het voegt semantisch gezien niets toe, wat bijvoorbeeld een 'required' attribuut op het element zelf wel doet.

Het voordeel ervan is dat het vanuit developers oogpunt wel super relaxed is.

Ik moet vaak grote invoerschermen maken voor web applicaties met allemaal (zeg een stuk of 100) input velden die eigenlijk per groep dezelfde validatie hebben. Als je die dan met een DOM selector selecteert, of a.d.h.v. een bepaalde className (waar ik het idd voornamelijk voor gebruik) scheelt dat je gewoon hoop werk met coden. Verder hoeft een validatie in een web applicatie wat mij betreft totaal niet semantisch te zijn want het is gewoon een stukje behavior.

[ Voor 6% gewijzigd door SchizoDuckie op 11-01-2008 22:04 ]

[crisp]

SchizoDuckie schreef op vrijdag 11 januari 2008 @ 22:01:
[...]

Sorry, maar i'm totally not impressed. Een niche browser met 0.2% coverage en het is onderdeel van een future spec. Voorlopig gebruikt 99% van de tuinders en omliggende vakgebieden (doelgroep van de organisatie waar ik momenteel werk) nog IE 5.5+. Ik snap de filosofie erachter, maar bruikbaar is het idee echt niet de komende paar jaren.

Het idee is wel buitkbaar aangezien er al crossbrowser javascript implementaties zijn die deze functionaliteit naar non-WF2 browsers porteren. Overigens kan je ervan uitgaan dat Safari en Firefox Opera wel zullen volgen mbt implementatie.

[...]

Het voordeel ervan is dat het vanuit developers oogpunt wel super relaxed is.

Ja, maar dan moet je jezelf eerst een compleet ander paradigma aanleren (ik heb overigens geen idee of en hoe andere libraries form-validatie aanpakken, maar vaak lijkt het er op dat iedereen het wiel opnieuw probeert uit te vinden).

Ik moet vaak grote invoerschermen maken voor web applicaties met allemaal (zeg een stuk of 100) input velden die eigenlijk per groep dezelfde validatie hebben. Als je die dan met een DOM selector selecteert, of a.d.h.v. een bepaalde className (waar ik het idd voornamelijk voor gebruik) scheelt dat je gewoon hoop werk met coden. Verder hoeft een validatie in een web applicatie wat mij betreft totaal niet semantisch te zijn want het is gewoon een stukje behavior.

Ik vind input-validatie niet puur behaviour, het is meer dan dat en alleen daarom wil je juist een sterkere koppeling hebben tussen het element en de verwerker, of dat nou een stukje javascript is of de UA zelf (die in jouw oplossing op geen enkele manier kennis kan nemen van eventuele extra constraints).

[ Voor 4% gewijzigd door crisp op 11-01-2008 22:39 ]

[SchizoDuckie]

crisp schreef op vrijdag 11 januari 2008 @ 22:34:
[...]

Het idee is wel buitkbaar aangezien er al crossbrowser javascript implementaties zijn die deze functionaliteit naar non-WF2 browsers porteren. Overigens kan je ervan uitgaan dat Safari en Firefox Opera wel zullen volgen mbt implementatie.
[...]

Idd, het idee is bruikbaar, maar gelukkig is de keuze vrij. Verder word ik ook nog 100% gebonden door bestaande functionaliteit en de heerlijkheid van struts 1.1 wat nogal kieskeurig is m.b.t. welke properties er wel/niet aan een element toegekend worden.

Ja, maar dan moet je jezelf eerst een compleet ander paradigma aanleren (ik heb overigens geen idee of en hoe andere libraries form-validatie aanpakken, maar vaak lijkt het er op dat iedereen het wiel opnieuw probeert uit te vinden).

Andere libraries pakken dit idd ook elk op eigen manieren aan. Ik ben al jaren bezig om iets te vinden wat ik én in no-time kan implementeren, én zichzelf beschrijft én flexibel genoeg is voor de functionaliteit die ik hierboven beschrijf, tot nu dus. Er wordt o.a. ook gebruik gemaakt van (imo ranzig) classes misbruiken alt tags misbruiken title tags misbruiken, complete eigen properties, plain javascript lappen code etc. Voordeel van mijn code is dat je een stukje javascript kan neergooien ergens random in de pagina, de onsubmit afvangen (of welk ander event dan ook) en klaar.

Ik vind input-validatie niet puur behaviour, het is meer dan dat en alleen daarom wil je juist een sterkere koppeling hebben tussen het element en de verwerker, of dat nou een stukje javascript is of de UA zelf (die in jouw oplossing op geen enkele manier kennis kan nemen van eventuele extra constraints).

Mja nogmaals, utopie. Imo leuk dat je nu al nadenkt over toekomstige niveaus van abstractie, en HTML forms die ooit automagisch ingevuld gaan worden door bots, maar mijn projectleiders willen *nu* een oplossing die niets anders doet dan een event valideren of het gevuld is volgens een bepaalde manier of niet, en of er een dependency aanzit, of niet, en daana mag het form gesubmit worden of wordt er een melding getoond.

ITT tot veel tools momenteel op het internet momenteel ga ik misschien tegen bepaalde filosofieën in (mijn PHP OR mapper heeft bijv. ook geen aparte XML config files per entity, maar dit staat gewoon keihard in de constructor van het object), maar je krijgt er wel een stukje flexibiliteit en snelheid voor terug tijdens het coden, hier en nu. In een per uur betaalde wereld is dat een hoop waard, mij meer dan de utopie van een paar toekomstige standaarden die er al jaren 'aan zitten te komen'.

[ Voor 3% gewijzigd door SchizoDuckie op 11-01-2008 23:05 ]