waarde in nested array via string als index

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Data Engineer/ ETL Developer/ Datawarehouse

Functieomschrijving WIl je data ontsluiten, transformeren en verwerken voor een organisatie die maatschappelijk een flinke steen bijdraagt? Ben je zelfstandig, ijverig en een echte teamplayer? Dan is deze functie voor jou! Reageer snel! Ontsluiten, transformeren en verwerken van data (ETL); Analyseren van verschillende bronsystemen; Plegen van overleggen met de business en leveranciers; Beheren van het data warehouse; Doorontwikkelen van de omgeving (kennis up to date houden). Functie-eisen HBO werk en denkniveau; Minimaal 5 jaar werkervaring met dataverwerking, waarvan minimaal 2 jaar als datawarehouse developer; Kennis van verschillende Microsoft tools als SSIS, SQL Server; Ervaren scripter (Powershell, cmd); Vloeiend Nederlands in

Bekijk vacature »

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

15/08/2020 10:16:37
 
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.
 



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.