Hoe begin je een low-code platform met Neo4j? – Frames en Views (3/4)

In deel 3 van 4 in deze serie wordt uitgelegd hoe (met het platform) webpagina’s ontworpen, gemaakt en gebruikt kunnen worden. Het is de ‘UI-engine’ van het platform dat (low-code) ontwikkelaars en eindgebruikers in staat stelt het platform te gebruiken.

Requirements

Flexibiliteit staat bovenaan de lijst, dus laten we dat begrip iets tastbaarder maken. Twee van de belangrijkste doelen hierbij zijn:

Het weergeven van elke soort data op elke manier — Elke specifieke uiting van data maakt het low-code stuk van het platform minder sterk. De pagina’s moeten dus elke soort gegevens weer kunnen geven op elke manier. Omdat we via Php/Symfony leunen op Twig, is de helft van het werk hiervoor al gedaan. Voor andere helft moeten we zorgen voor het consumeren van de generieke data op een slimme manier.

Inline data ophalen/acties— Er is ook gedrag nodig: Er moet iets gebeuren als de gebruiker ergens op klikt. Normaal gesproken wordt er meer/andere data geladen of worden er acties uitgevoerd door het systeem.

Meta model voor Screens

Voor het genereren van schermen kunnen veel richtingen gekozen worden. Het onderstaande model is nog onvolledig, maar geeft een goed beeld van wat er mogelijk is. Het toont de kracht aan van een paar eenvoudige concepten:

Meta model voor Screens

Een scherm dat in Symfony  geladen wordt via een URL kan bestaan uit normale HTML of uit een symfony/twig pagina. In de PoC heb ik het concept van Frames toegevoegd (de ../Frame/.. en ../FrameN/..-routes). Als een Frame geladen wordt, gebeurt er het volgende:

• Het Frame en haar startView worden geladen, gerenderd en naar de browser gestuurd.
• De browser voert wellicht een onLoad aan (als onderdeel van de pagina), waar het andere Views kan laden (met een of meerdere ajax-calls).
• Als de pagina volledig geladen is, kan de gebruiker een element aanklikken dat weer een nieuwe View/Frame laadt. Voor elke View moet de context (het metaType) opgegeven worden, dus de back-end weet welke parameters het aan de view-queries moet leveren).

Het gebruik van Twig is een goede technologie om de functionaliteit te leveren die nodig is voor dit meta model. De veelzijdigheid van Twig helpt dankzij haar recursieve en inclusion methodes om snel Frames en Views samen te stellen en op te delen in elke granulariteit.

Elke View heeft een Query in zich. De Query haalt de data op die voor de View nodig is. In een volwaardig platform zou dit geen rauwe Query zijn, maar zou de Query samengesteld worden door door het meta model van een domein te klikken en de Nodes, Relaties en Attributen te selecteren die je weer wilt geven.

Hoe zien Frames en Views er uit?

Alles wat je ziet in de PoC is gemaakt van Frames en Views. De pagina’s van de Databrowser en Data editor (genoemd in deel 2) zijn ook samengesteld uit Frames en Views. En omdat het gebouwd is met html/twig, kun je het het uiterlijk geven dat je zelf wilt. Voor de lezer die de PoC nog niet geprobeerd heeft, het ziet er zo uit:

Beetje vreemd: De Data Browser is samengesteld uit Frames and Views en is gedefinieerd met haar eigen functionaliteit.

Voor nu dus standaard bootstrap. 🙂

Belangrijker is dat de functionaliteit van Frames en Views samen met de DataBrowser en Data Editor een op zichzelf staande data invoer- en weergeef-applicatie vormen waarmee je een groot scala aan datastructuren kan bewerken. Zelfs voor haar eigen data.

Nog een stap verder met het Screens meta model

Om de veelzijdigheid van het Screens meta model te demonstreren heb ik het volgende toegevoegd:

View Controller (Functional module) — Bevat standard Frames en Views voor datastructuren en instanties.

In de repository (zie onder, in de /examples map) zit een voorbeeld database met F1 data om de kracht van deze Frames en Views aan te tonen. Het concept wordt hieronder ook uitgelegd maar, geloof me, het is beter om het in actie te zien.

De URL in het voorbeeld start met een pagina zoals in het figuur hieronder.

Automatisch wordt ‘2020’ geselecteerd, maar die heeft helaas nog geen data omdat er nog geen races gereden zijn. Dus laten we seizoen 2019 selecteren. Dit zorgt ervoor dat 2019 in de middelste kolom weergegeven wordt en dat de resultaten voor de eerste View geladen en getoond worden: Constructor championship results. Als je nu op  Races in Season klikt, dan ziet de pagina er ongeveer zo uit:

Vanaf hier kun je doorklikken op de instanties in de tabellen. Klik bijvoorbeeld op Spanish Grand Prix (rechtsonder). Na het klikken zal de rechter View verplaatst worden naar de linkerkant en de context (het metaType) in het midden zal veranderen naar Race (omdat je een item van type Race hebt geklikt). Daarna zullen de Views relevant voor die context geladen worden als knoppen. In dit geval de Race Results voor de 2019 Spanish Grand Prix:

Door op “Spanish grand prix” te klikken, wisselt de context van de middelste view naar Race (en worden de corresponderende Views hiervoor getoond)

Het is ook mogelijk om op de naam van het Circuit te klikken (Circuit de Barcelona-Catalunya). De context verandert dan naar Circuit en toont de Views voor die context:

Door op de naam van een Circuit te klikken, wisselt de context van de middelste View naar Circuit (en toont de corresponderende Views)

Dit toont alle seizoenen waarin een Race op dit Circuit werd gehouden en welke Driver deze Race heeft gewonnen. Zo kun je rondklikken door alle data. Je kunt op elke Season, Circuit, Driver, Constructor of Race klikken. Als je van F1 houdt, veel plezier. 🙂

Het is eenvoudig om Views aan een context toe te voegen door een nieuwe View te maken, er een Neo4j query voor te schrijven en de context (het metaType) te selecteren. De View Node with Queries haalt dan alle Views op die gerelateerd zijn aan dat metaType en de View template maakt de knoppen om ze te laden.

Laatste stap: Oneindige veelzijdigheid

Bovenstaande toont de veelzijdigheid aan van het meta model voor Screens dat samenwerkt met de View Controller. Wat nu als dit een volledige applicatie is? Wat zouden de mogelijkheden dan zijn?

Dit is waar modulariteit en Functionele modules om de hoek komen. Het is volledig aan je eigen creativiteit om de bedenken wat je het platform wilt laten doen. Maak het generiek (of specifiek) en stop het in een Functionele module.

Hoe dat gebeurt wordt in deel 4 uit de doeken gedaan.

Neem een kijkje in de keuken: De PoC staat op Github, zodat je de werking van het platform kan bestuderen. Hij si hier te vinden: GitHub — InfoNotion. (Als je bij wilt dragen of samen iets wilt bouwen, stuur een berichtje!)