waarde in nested array via string als index

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Ad Fundum

Ad Fundum

13/07/2020 18:18:40
Quote Anchor link
Hoe kan je op een elegante manier de waarde krijgen van $_POST['item'][2]['waarde'] als je alleen een Unicode string hebt met met daarin de originele HTML ID 'item[2][waarde]' ?
 
PHP hulp

PHP hulp

29/03/2024 14:27:58
 
Thomas van den Heuvel

Thomas van den Heuvel

13/07/2020 19:32:30
Quote Anchor link
Misschien wat meer context? Met welk ontwerp kom je hierop uit?
 
Rob Doemaarwat

Rob Doemaarwat

13/07/2020 19:35:19
Quote Anchor link
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
<?php

$key
= 'item[2][waarde]';
$value = $_POST;
foreach(explode('[',str_replace(']','',$key)) as $key)
  if(!is_array($value = $value[$key] ?? false)) break;
var_dump($value); //false indien niet gevonden

?>
(sambal bij?)
Gewijzigd op 13/07/2020 19:41:18 door Rob Doemaarwat
 
Thomas van den Heuvel

Thomas van den Heuvel

13/07/2020 19:40:03
Quote Anchor link
Dat lijkt mij voortborduren op een slecht ontwerp.
 
Ad Fundum

Ad Fundum

13/07/2020 22:36:00
Quote Anchor link
Bedankt Rob!

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.
 
Thomas van den Heuvel

Thomas van den Heuvel

13/07/2020 23:38:17
Quote Anchor link
Ik kan mij niet voorstellen dat als je dit wat anders aanvliegt in HTML/JavaScript (dynamische formulieropbouw?), dat je dit niet netter kunt oplossen.

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 komt gewoon nodeloos complex over.

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
 
Rob Doemaarwat

Rob Doemaarwat

13/07/2020 23:55:13
Quote Anchor link
Geen idee wat de context is. Boeit me ook niet. Ik kom hier puur om mezelf te voorzien van "eenvoudig" vermaak. Ik kan me echter wel een paar "use cases" voorstellen waar ik zelf tegenaan gelopen ben (en op eenzelfde manier heb opgelost).

- 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.
 
Ad Fundum

Ad Fundum

14/07/2020 09:37:04
Quote Anchor link
Mijn applicatie waar dit in voorkomt is groot en bestaat al sinds Windows XP met Internet Explorer 6. In die tijd heb ik een aversie tegen JavaScript opgelopen vanwege beperkingen in browsers. De applicatie heeft interactieve formulieren gekregen waarbij alles loopt via XHR-verzoeken. Uiteindelijk moest toch alles op de server worden geregeld, inclusief validatie. Formulieren bouw ik dynamisch op vanuit tabellen en resultaten van SELECT-statements. Dus je kunt niet zeggen dat er geen nood is om het te maken zoals het gemaakt is. Het voldoet nog steeds aan de vraag vanuit de business.

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.
Gewijzigd op 14/07/2020 09:47:58 door Ad Fundum
 
Thomas van den Heuvel

Thomas van den Heuvel

14/07/2020 15:56:52
Quote Anchor link
Okay, dus dit kun je niet 1-2-3 aanpassen omdat het mogelijk uitgebreid / legacy is. Dan zul je min of meer moeten werken met wat je hebt. Fair enough.

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.
 
Ad Fundum

Ad Fundum

14/09/2020 16:27:43
Quote Anchor link
Ik heb het nu dan toch in mijn eigen raamwerk ingebouwd, want het is wel handig.
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)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
<?php
$mijn_array
= [ ... ];
$xml = new SimpleXMLElement('<root/>');
array_walk_recursive($mijn_array, [$xml, 'addChild']);
?>
Gewijzigd op 14/09/2020 17:09:51 door Ad Fundum
 
Thomas van den Heuvel

Thomas van den Heuvel

14/09/2020 17:34:23
Quote Anchor link
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?
 
Ad Fundum

Ad Fundum

14/09/2020 17:48:05
Quote Anchor link
Die eerste suggestie is wat Rob ook zegt, maar waarom zou je alles van te voren uit laten rekenen.
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.
Gewijzigd op 14/09/2020 18:48:39 door Ad Fundum
 



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.