waarde in nested array via string als index
Het kan altijd beter Thomas. Ik ben bezig met formulieren die een setje gegevens in meervoud kunnen insturen.
In aanloop was ik wat aan het rommelen om dat goed te krijgen, omdat mijn formulieren in principe plat zijn.
Inmiddels kom ik op een ontwerp met een class die dient als groepering van formuliervelden, dus met een n:m-relatie.
De $_POST variabele is daarbij het probleem niet, maar in het proces kwam ik op bovenstaande vraag, en dacht dat het wel leuk zou zijn om die hier te stellen.
Je bent nu in wezen je eigen informatie handmatig aan het decoderen. Dit klinkt gewoon als een barrière die je zelf hebt opgeworpen. Dat kan nooit een goed uitgangspunt zijn voor een (formulier)ontwerp.
Sure, dit zal werken, maar het is
Het is simpel om iets ingewikkeld te maken, maar je zult wat extra moeite moeten doen om alles eenvoudig te houden.
Gewijzigd op 13/07/2020 23:40:35 door Thomas van den Heuvel
- In m'n validatieregels kan ik bijvoorbeeld via een constraint aangeven dat "item[waarde] >= item[andere]". Dit betekent dan dat voor elke "i" (die de plaats van de "*" inneemt) de "waarde" groter of gelijk moet zijn dan de "andere". Dan noteer je dat op deze manier, en moet je inderdaad een beetje goochelen om de juiste waarde op te halen (ter info "*--" = "vorige regel" mag ook).- Ivm de HTML4 spec kon je in je in een HTML element ID geen blokhaken gebruiken. In plaats daarvan gebruik ik dan dubbele underscores (dus name="item[2][waarde]" id="item__2__waarde"), dan krijg je ook dit soort knutselwerk (alhoewel mn aan de js kant).
En zoals Ad al zegt. Niet alles hoeft altijd "perfect" te zijn (je gaat niet steeds alles omgooien omdat je theoretisch ergens een komma kunt besparen). Soms moet je ook gewoon praktisch blijven en zaken "recht toe recht aan" oplossen.
Maar inmiddels hebben we HTML5 en is zelfs Microsoft Edge gebaseerd op Webkit. Ook ben ik er achter gekomen dat er onder PHP-ers geen consensus is over wat MVC in PHP zou moeten zijn. Achteraf gezien is dat logisch omdat MVC er eerder was dan PHP, en niet volledig past op het paradigma van stateless pagina's.
Het begrip 'model' is mij niet duidelijk, zo wordt er onderscheid gemaakt tussen active-record, domain models en weet ik wat niet meer. Ik heb geprobeerd zoveel mogelijk MVC aan te houden, maar het is eigenlijk van de gekke om alles wat met data te maken heeft in PHP te doen, terwijl ik aan de achterkant Postgres ter beschikking heb. Met views en functions kan alles wat bij mij 'model' is in de database, zelfs sessiebeheer.
En dan kom ik op de 'view', in feite is de browser zelf de view op het programma. Het is tegenwoordig inderdaad handiger om alles wat in de browser leeft, te doen met JavaScript. Daar ben ik ook naar toe aan het werken.
De controllerfunctie blijft over voor PHP. Mijn doel is om om het volledig asynchroon te maken, naar het voorbeeld van amphp.
Wanneer je vraagt om een aanpak dan schrijft de context meestal al voor een groot deel voor wat mogelijk is, of in welke richting je een oplossing moet / kunt zoeken. Dat is de reden dat ik hier naar vroeg.
Wat MVC is en hoe je ermee omgaat is waarschijnlijk een wat andere discussie. Een van de betere comments die ik daar over gelezen heb is dat je niet moet vergeten dat MVC een idee is, en daarom best verschillende verschijningsvormen kan hebben, afgestemd op wensen. Om dat dus te zeggen dat MVC er zus of zo uit zou moeten zien is het paard achter de wagen spannen.
De vorm zou nooit leidend moeten zijn, maar als je een "betere" vorm kunt vinden en kunt toepassen, dan is er geen reden om dat niet te doen. Dat is de reden dat ik voorstelde of de aanpak niet anders kon, want de huidige vorm is nou niet bepaald optimaal.
PHP maakt van de waarden van de HTTP POST automatisch een array. Meestal is dat fijn, soms niet.
Als je gemakkelijk aan een speciek ID wil kunnen refereren via een string, in je eigen functie heb je geen andere keuze dan $_POST aflopen op de manier van Rob.
Voor een vergelijkbare hiërarchische structuur als XML bestaat ook XPath, maar voor indices van geneste arrays moet je het zelf doen. Voor complexere queries zou het nutting kunnen zijn een array om te zetten in XML:
Code (php)
1
2
3
4
5
2
3
4
5
<?php
$mijn_array = [ ... ];
$xml = new SimpleXMLElement('<root/>');
array_walk_recursive($mijn_array, [$xml, 'addChild']);
?>
$mijn_array = [ ... ];
$xml = new SimpleXMLElement('<root/>');
array_walk_recursive($mijn_array, [$xml, 'addChild']);
?>
Quote:
Als je gemakkelijk aan een speciek ID wil kunnen refereren via een string, in je eigen functie heb je geen andere keuze dan $_POST aflopen op de manier van Rob.
Of je converteert het direct naar een tweedimensionaal array volgens het stramien dat @Rob voorstelt?
Quote:
Voor complexere queries zou het nutting kunnen zijn een array om te zetten in XML:
Of je gebruikt JSON, dan kun je overal op een makkelijke(re) manier bij je data?
En hoe zie je JSON voor je?
In mijn raamwerk zit ik met de situatie dat er een formulier gegenereerd is met een n:m-relatie, vandaar de keuze voor een ID met haken. Alleen ging dat tegenstaan op het moment dat ik callbacks via XHR had toegevoegd op basis van een aantal formuliervelden, waarbij ik dus met het HTML ID (met haken) moest kunnen verwijzen naar de $_POST waarden.
Slecht ontwerp? Nee.
Mooier zou natuurlijk zijn als ik alles wat met een View te maken had zou kunnen uitbesteden aan de browser. Maar ik word echt niet blij van JavaScript in Internet Explorer. Dus ik moet daar nog even mee wachten totdat de klant een betere standaardbrowser heeft.