Van PHP naar low-code met Mendix

Ben je als programmeur toe aan een nieuwe uitdaging? Dan is de overstap naar Mendix-engineer waarschijnlijk niet de eerste mogelijkheid die er bij je opkomt. Toch is het heel goed mogelijk om deze stap te zetten. Natuurlijk zijn er essentiële verschillen tussen programmeren en modelleren, maar dit hoeft zeker geen obstakel te zijn. Een van onze Mendix-engineers, Dennis Homberg, maakte deze overstap ruim drie jaar geleden en hij vertelt je hoe hij zijn eerste twee maanden bij Appronto heeft ervaren.

Mijn eerste twee maanden als Mendix-engineer

Toen ik bij Appronto kwam werken, had ik nog helemaal geen ervaring met Mendix. Ik had dankzij mijn achtergrond in PHP wel basiskennis van logische functies en architectuur en ik hoopte dat die me zou helpen bij de overstap. In die wetenschap accepteerde ik de kans die Appronto me bood. De uitdaging om te leren hoe je met een low-codeplatform snel applicaties modelleert, ging ik dan ook graag aan!

De overgang van programmeren naar modelleren verliep eigenlijk heel soepel, maar er waren een paar stukjes van de puzzel die enige tijd nodig hadden om op hun plaats te vallen. En uiteraard waren deze stukjes achteraf gezien heel belangrijk! Daarom vertel ik je graag over een paar ‘openbaringen’ die ik in deze periode had.

Microflow-parameters

Als ontwikkelaar was ik gewend om waarden in variabelen en sessies op te slaan bij het overbrengen van gegevens van de ene pagina naar de andere. In een modeller wordt echter bijna alles met visuele elementen weergegeven. Ik probeerde te achterhalen welke elementen ik nodig had om een vergelijkbaar mechanisme te creëren om gegevens door te geven.

De meeste activiteiten binnen een microflow zijn vrij eenvoudig: haal een object (of een lijst met objecten) op, doe er iets mee en toon een pagina. Wat ik echt niet begreep, was waar de parameters die binnen een microflow worden getoond, worden gedefinieerd of hoe je een bepaald object kon doorgeven en ‘onthouden’ voor toekomstige referentie.

Nadat ik een tijdje een bestaande applicatie had verkend en hulp van collega’s had gekregen, begreep ik dat parameters op verschillende manieren naar een microflow kunnen worden gestuurd:

• Vanuit een bovenliggende widget, zoals een lijstweergave of datagrid.Dit is een datagrid die alle objecten toont van een entiteit ‘Medewerkers’ met als enige attribuut ‘Naam’. Wanneer je ‘Bernie’ selecteert en op ‘Microflow actie’ klikt, is de parameter die van de microflow voor het specifieke object met ‘Naam’ = ‘Bernie’.
• Vanuit een andere microflow. Je kunt namelijk binnen een microflow een andere bestaande microflow aanroepen. Deze worden meestal subflows genoemd. Met een subflow kun je elk gegevenstype doorgeven dat beschikbaar is in de oorspronkelijke microflow.

Het end event in microflows

Nu ik helder voor ogen had hoe parameters in Mendix werken, was mijn volgende vraag aan de beurt. End events. Iedere microflow heeft een begin en minimaal één end event. In de meeste microflows die ik bestudeerde, waren er end events zonder label of tekst. Ze hadden parameters, activiteiten en openden specifieke pagina’s. Ze gaven een bericht weer of wijzigden een object en sloten de microflow keurig af. Er waren echter ook microflows waarvan het end event bijschriften bevatte, zoals ‘Lijst van werknemers’ of een Boolean-waarde. Ineens viel er nog een puzzelstuk op zijn plaats: de retourwaarde!

Wanneer je een enkel object wilt ophalen, maar er zijn 12 activiteiten nodig om dat object te krijgen, verstoort dit je microflow. Het komt ook de leesbaarheid van je microflow niet ten goede. In plaats daarvan kun je een subflow instellen om dit object op te halen en deze te retourneren aan de bestaande microflow. Het retourneren van objecten, lijsten, Booleans enzovoorts is niet alleen handig in subflow. Je kunt het ook gebruiken in microflows die fungeren als een gegevensbron voor een widget.

Toen ik de in- en uitvoer van microflows doorhad, was het lezen van bestaande microflows een stuk eenvoudiger. En, ik kon als uit het niets ineens nieuwe microflows maken voor de functionaliteiten die ik wilde implementeren.

Associaties

De eerste keer dat ik aanschoof bij een van mijn nieuwe collega’s, merkte ik hoe snel hij werkte. Ik probeerde te begrijpen hoe hij attributen van verschillende entiteiten in één datagrid, of zelfs een pagina, kon weergeven. Ik had het domeinmodel de dag ervoor bestudeerd en de associaties tussen entiteiten gezien. Maar de betekenis van die pijlen en lijnen had ik niet volledig begrepen.

Aangezien Mendix voldoende documentatie over dit onderwerp heeft, zal ik niet in detail ingaan op de associaties. Kenmerken van verschillende entiteiten naar een datagrid van de connectortool slepen, is relatief eenvoudig als je de verbindingen tussen de entiteiten eenmaal begrijpt. De echte eye-opener voor mij was het gebruik van gegevensweergaven om de context in te stellen op een specifieke entiteit. Zelfs als de entiteit uit een heel andere module aangeroepen wordt. Daarna kun je de connectortool gebruiken om de attributen die wilt laten zien op de pagina die je bouwt te plaatsen.

XPath-expressies waren een ander ding waar ik in het begin nogal mee worstelde. Vooral wanneer je verschillende associaties volgt om bij de gewenste entiteit te komen, kan de uitdrukking vrij lang worden. Dan helpt het echt om het domeinmodel ernaast te houden, terwijl je deze lastige XPath-expressies instelt. In ieder geval totdat je alle associaties kent en begrijpt.

%CurrentObject

Voor een nieuw project waar ik aan werkte, vroeg ik mijn collega’s hoe ik het beste een database-retrieve kon instellen. Vaak zag ik ze het token %CurrentObject% gebruiken in de XPath-expressie. Wanneer je met een datagrid werkt, leek me dat vrij logisch. Het geselecteerde object in dat specifieke datagrid is het %CurrentObject%. Maar toen ik zag dat hetzelfde token ook werd gebruikt binnen een gegevensweergave, stond ik toch even verbaasd te kijken. Gelukkig kwam ik er al snel achter dat de directe ‘parent’ van de widget waarmee je werkt als het huidige object wordt beschouwd.

Laat ik er even een voorbeeld bij pakken:

• We hebben twee entiteiten: ‘Werknemer’ en ‘Schoen’. De laatste heeft een string attribute ‘color’
• We gebruiken een lijstweergave om alle werknemers te tonen en daarin een andere lijstweergave met alle schoenen van de betreffende werknemer die een andere kleur dan blauw hebben.

In de ideale situatie zouden we de associatie tussen de twee entiteiten willen gebruiken om de geneste lijstweergave te vullen. Maar dan zou deze weergave ook alle blauwe schoenen laten zien die een werknemer bezit. Juist vanwege deze kleurbeperking moeten we een XPath-expressie gebruiken en dit is waar het token %CurrentObject% een rol speelt.

De resulterende uitdrukking is als volgt:

[MyFirstModule.Shoe_Employee = ‘[%CurrentObject%]’]
[Color != ‘Blue’]

Het token %CurrentObject% in deze uitdrukking, is de werknemer uit de ‘bovenliggende’ lijst. Hiermee worden de objecten ‘Schoen’ opgehaald die aan een medewerker zijn gekoppeld, maar die met het kleur-kenmerk ‘Blauw’ zijn uitgesloten.

Eureka-momenten en een laatste tip

Dit zijn een paar van de eureka-momenten die me echt geholpen hebben mijn vaardigheden te ontwikkelen.

Als je als programmeur de overstap wilt maken naar modelleren met Mendix, raad ik je aan om op zijn minst de eerste -gratis- cursus die Mendix aanbiedt op hun website te bekijken. Deze geeft je inzicht in het domeinmodel, wat een visuele presentatie is van de structuur van de database, met entiteiten als de tabellen, en hoe je objecten kunt ophalen, wijzigen en opslaan.