(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Webbutvecklingsdagbok - efter studierna
Visa signatur
Visa signatur
MSI PRO Z790-P WIFI | Intel i9 13900K | 128 GB DDR5
GTX 4070 12 GB
Samsung 990 Pro 4 TB | WD Black SN850X 2 TB Gen 4 | 2 x 1 TB Samsung 970 EVO Plus
3 x ASUS 27" | 1 x Philips 49"
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Webbutvecklingsdagbok - efter studierna
Jobb & Uppdrag
Förrförra samt förra veckan fick jag gott om jobb från Stockholmskunden medan denna vecka så blev det avsevärt mycket mindre. Förhoppningsvis blir sista veckan denna månad tillräckligt för att inte behöva börja blöda buffert.
Jag har nu två .bat-filer som innehåller alla de tre första stegen när jag mottagit jobb från Stockholmskunden och sedan för att kunna automatisera saker när jag själv vet antalet sidorna inuti varje PDF-fil:
rem "_123_Prepare_Ebooks.bat"
@echo off
setlocal enabledelayedexpansion
rem Step 1: Remove "PDF_" prefix
for %%f in (PDF_*.pdf) do (
set "filename=%%~nxf"
set "newname=!filename:PDF_=!"
ren "%%f" "!newname!"
)
rem Step 2: Replace spaces with underscores
for %%f in (* *.pdf) do (
set "filename=%%~nxf"
set "newname=!filename: =_!"
ren "%%f" "!newname!"
)
rem Step 3: Add "-WKF-s" to the end of all filenames
for %%f in (*.pdf) do (
set "filename=%%~nxf"
set "basename=%%~nf"
set "newname=!basename!-WKF-s.pdf"
ren "%%f" "!newname!"
)
echo Removed _PDF and whitespaces and added WKF with s at the end.
cd /d "%~dp0"
for %%f in (*.pdf) do (
rem Extract the file name without the extension
set "basename=%%~nf"
rem Create a folder with the same name if it doesn't exist
if not exist "!basename!" (
mkdir "!basename!"
)
rem Move the PDF file into the folder
move "%%f" "!basename!\"
)
echo Moved all PDFs into their respective folders.
rem Set the template file names (adjust these if your template names are different)
set "templateHTML=ISBN-Boknamn-v1-WKF.html"
set "templateDOC=ISBN-Info-BokNamnSVENSK-v1-WKF-Ljudbok.doc"
rem Loop through each directory (folder) in the current folder
for /d %%D in (*) do (
rem Store the folder name in a variable
set "foldername=%%D"
rem (Optional) You could add a check here if you only want to process folders that contain a PDF
rem e.g. if exist "%%D\*.pdf" (
rem --- Copy the HTML file ---
rem The new copy gets the same name as the folder, with .html extension.
copy /y "!templateHTML!" "%%D\!foldername!.html"
rem --- Copy and rename the DOC file ---
rem We need to insert "-INFO" after the ISBN digits.
rem Use a for /f loop to split the folder name into the ISBN (digits) and the rest.
for /f "tokens=1* delims=_" %%a in ("!foldername!") do (
set "isbn=%%a"
set "remainder=%%b"
)
rem Construct the new DOC file name.
set "newDocName=!isbn!-INFO_!remainder!.doc"
copy /y "!templateDOC!" "%%D\!newDocName!"
rem ) <- End of optional check if needed.
)
echo Copies created for each folder.
pause
rem "_1234_AddPageNumbersToFiles.bat"
@echo off
setlocal enabledelayedexpansion
rem Function that renames all files in current directory with the provided page number (%1)
:RenameFiles
set "current=%1"
for %%f in (*.*) do (
if /i not "%%~nxf"=="_4AddPageNumbersToFiles.bat" (
set "filename=%%~nxf"
set "newname=!filename:WKF-s=WKF-%current%s!"
ren "%%f" "!newname!"
echo Renamed "%%~nxf" to "!newname!"
)
)
rem Loop through all directories and use the indexed array value using the i variable as counter
for /d %%d in (*) do (
echo.
echo Entering folder: %%d
set "folderName=%%d"
set "temp=!folderName:-WKF-=#!"
for /f "tokens=2 delims=#" %%x in ("!temp!") do set "extractedNumber=%%x"
set "extractedNumber=!extractedNumber:s=!"
echo Extracted Number: !extractedNumber!
pushd "%%d"
call :RenameFiles !extractedNumber!
popd
echo Exited folder: %%d
)
echo Added Page Numbers to Files.
endlocal
pause
En annan sak jag försökt automatiserat med AutoHotKey (AHK) är att kunna lägga in kommentarer snabbare i PDF-filerna men dessvärre så blir det fel med hur AHK tolkar x- & y-koordinaterna inuti Adobe Acrobat-klienten.
Igår så hade jag min allra första telefonintervju som självutnämnd IT-frilanskonsult med en ny potentiell Uppdragsgivare inom webbutveckling vilket kom som resultatet av en person jag har kontakt med i en viss Discord-grupp.
Jag fick frågor om vad jag pysslade med om dagarna, även min tidigare universitetsutbildning inom folkhälsa vilket ej är relevant längre. Men den nya potentiella Uppdragsgivaren tog upp det då det möjliga uppdraget på mellan 1-2 månader på antingen del- eller heltid med ett arvode på mellan 500-600 kr/tim är just inom hälsa.
Denna Uppdragsgivare väntar dock själv på finansieringsbesked från slutkund och utan det så blir det inget uppdrag där jag skulle kunna bli den valda frontend-utvecklingskandidaten vilket är vad rollen skulle infatta. Frontend-utveckling inom senaste versionen av ReactJS och React Native. (ja, en webbapplikation plus en mobilapplikation!)
Den nya potentiella Uppdragsgivaren är medveten om att jag är en nyutexaminerad junior fullstacks-webbutvecklare sedan maj 2024 och har erhållit min GitHub där jag då lagt upp tidigare relevant ReactJS-projekt. Personen kommer att komma med återkoppling om ett par veckor även om det innebär att bara meddela att de gått vidare med en annan kandidat.
Hobbyprojekt
Tre icke-rekursiva funktioner för att hitta ett bestämt Fibonacci nummer - utan LLM-hjälp!
När jag skummade igenom en mycket förenklad programmeringskurs i Python så kom ämnet rekursion upp i kursen och det klassiska exemplet på att hitta Fibonacci nummer x. Problematiken här är så klart att med rekursion så blir det stacköverflöde omedelbart.
Kursen bad en då att pausa och fundera hur en icke-rekursiv funktion kunde skrivas för att hitta Fibonacci nummer x. Jag lyckades då skriva tre olika icke-rekursiva funktioner som kan hitta Fibonacci nummer x vid anrop utan att drabbas av stacköverflöde - och detta utan någon hjälp av LLM. Däremot googlade jag upp metoderna för arrayer i JS. Självfallet kraschar även dessa implementeringar vid tillräckligt stora Fibonacci nummer som sökes.
De tre olika varianterna är:
1. Endast med primitiva variabler.
2. Array utan stack.
3. Array med stack.
const fibb = 6;
console.time("test");
console.log("Fibbo PRIM nr("+fibb+"): " + fibboPrim(fibb));
console.timeEnd("test");
function fibboPrim(n)
{
let tempPrev = 1;
let tempNext = 1;
let twoLast = 0;
if(n == 0) {return 0;}
else if(n == 1 || n == 2) {return 1;}
for(i=2; i < n; i++)
{
twoLast = tempPrev+tempNext;
tempPrev = tempNext;
tempNext = twoLast;
console.log("TempPrev: " + tempPrev + " | tempNext: " + tempNext + " | twoLast/Sum: " + twoLast);
}
return twoLast;
}
console.time("test2");
console.log("Fibbo ARR nr("+fibb+"): " + fibboArray(fibb));
console.timeEnd("test2");
function fibboArray(n){
const arr = [0,1,1];
if(n == 0) {return 0;}
else if(n == 1 || n == 2) {return 1;}
for(i=2; i < n; i++)
{
arr.push(arr[arr.length-1]+arr[arr.length-2])
}
return arr[arr.length-1];
}
console.time("test3");
console.log("Fibbo STACK nr("+fibb+"): " + fibboStack(fibb));
console.timeEnd("test3");
function fibboStack(n){
let num = 0;
const stack = [1,1];
if(n == 0) {return 0;}
else if(n == 1 || n == 2) {return 1;}
for(i=2; i < n; i++)
{
let next = stack.pop();
let prev = stack.pop();
num = next+prev;
if(i > n){break;}
stack.push(next);
stack.push(num);
}
return num;
}
Jag kallar första funktionen för primitiva tal då jag endast "växlar" med att lagra de två senaste numren som sedan då kan generera nästa nummer tills önskvärd Fibonacci nummer x har uppnåtts eller programmet kraschat.
Observera i den tredje funktionen där en array med stack tillämpas - det vill säga kika i loopen. En liten detalj för att verkligen "optimera" användningen av stackens storlek. Den andra funktionen är den som visades upp som alternativ icke-rekursiv funktion men där insåg jag då att då växer arrayen och därmed rymdkomplexiteten (eng. space complexity).
Frågan är då istället om det bara blir något annat som ökar i Ordo i och med elementen som tas bort och läggs till i array-stacken? 🤔 Om jag minns rätt så är Array.pop() och Array.push() båda Ordo(1).
9 Månader sedan senast Git Commit i projekt efter studierna!?
I skrivande stund är det exakt nio månader sedan jag gjorde mitt första Hobbyprojekt på GitHub efter avslutade webbutvecklingsstudier på distans. Se första bilden nedan:
Jag hade en väldigt omfattande katalog- och filstruktur för min egen del tycker jag:
Det av intresse är hur jag nu när jag tittar tillbaka på vissa delar är att jag nu förstår viss kod mycket bättre nu än jag gjorde då. Koden var "kommentarsskriven LLM-kod" vilket betyder att jag skrev kommentarer och sedan autoifylldes resten av CoPilot:
Koden från de två ovanstående bilderna visar en funktion vars "enda syfte" egentligen var att matcha en URI-rutt vare sig det är dynamiskt (t.ex. "/users/{id}") eller statiskt (t.ex. "/login").
Dessvärre gör funktionen lite för mycket och en kodrad jag först inte kunde förstå riktigt för nio månader sedan även fast jag kunde läsa den var raderna 79-80 där den först ersätter alla {dynamiska_parametrar_i_rutten} med Regex-vänliga strängvärden för att sedan testa att matcha nuvarande inkommen URI-rutt mot den.
På något vis så "fattade" jag inte riktigt första raden (79) trots att jag läste stirrandes på den. Nu "kopplar" det helt enkelt även fast jag fattade vad båda raderna tillsammans gjorde för syfte. Det var nog att jag inte bara kopplade exakt hur* det gick till.
(* Sanning med modifikation så klart eftersom jag varken förstår Zend-motorn ut och in och/eller den faktiska maskinkoden som körs!😬)
Hursomhelst, vad som behövs för det 99 % funktionsbaserade och mycket avskalade PHP-ramverket är lustigt nog smalare funktioner - mer åt "Single Responsibility"-hållet.
Tanken är att endast matcha en hårdkodad rutt mot den nuvarande URI-rutten även om den hårdkodade rutten ifråga har dynamiska strängar inuti sig. Sedan när det är klart så ska andra funktioner hantera saker som att extrahera information om vad som då gäller för den matchade rutten vilket nu denna rutt försöker hålla på med vilket blir för mycket för att hålla reda på inuti samma funktion upplever jag.
Med andra ord kan en annan funktion extrahera alla konfigurerade variabler till den matchade rutten eftersom den nu är känd och så kan en ytterligare annan funktion extrahera potentiella {dynamiska_parametrar_värden} från den matchade rutten då detta brukar behövas för att sedan dynamiskt kunna hämta relevant databasdata.
En annan sak jag funderat på är något jag sett på YT sedan nio månader gått vilket är att, "Börja med att bara få det att fungera", dvs., MVP eller kanske MLP för att krydda till det hela lite. När jag började med detta projekt för nio månader sedan så kunde jag fundera på allt jag ville skulle fungera direkt vid första steget i "Matcha rutt - hämta data - svara med förrenderad HTML".
Exempelvis ville jag redan kontrollera mot databas för autentisering trots att jag inte ännu hade funderat ut på alla möjliga former av autentiseringsstöd, rollbaserad autentisering, hur tabellerna skull se ut standardmässigt, och så vidare.
Det får helt enkelt bli en mindre sak i taget och sedan bara få ihop den så kallade "Hello World!"-versionen av RDP vilket jag kallar projektet för vilket står för "RouteDataPage" då flödet på webbplatser tenderar att följa den vägen. (ja, vissa har bara RouteData i fallen med API:er!)
Vidareutbildning
En sak jag tänkt på gällande "Konsten att tänka som en programmerare" är när vi zoomar in mer på "algoritmtänkandet", dvs., när vi väl ska tackla ett givet mindre problem som vi fått fram genom att delat upp ett större problem i mindre och sannolikt mer lösbara problem.
Jag reflekterar tillbaka till något YT-klipp jag såg om "Vanliga olika algoritmmönster för att lösa majoriteten av Leetcodes" och när jag såg det så inser jag nu att det är ju inte bara för det ändamålet: Det är ju faktiska "stegmönster" att följa i samband med framtagningen av en given algoritm för att lösa ett mindre problem.
Ett mönster - fritt översatt på svenska av mig - kallas för "Skjutfönstret" vilket handlar om att föreställa sig ett "fönster som skjuts åt sidan och varje gång det skjuts åt sidan så kontrollerar du vad du fokuserat fönstret på".
Med andra ord? En loop där du kontrollerar ett bestämt antal steg framåt via index trots att indexet kanske bara ökar med 1 i taget. Exempel på där detta algoritmmönster kan vara användbart är om du vill kontrollera om något ord i en viss storlek finns inuti ett annat.
Säg att du vill kontrollera för tre tecken i taget då vill du kanske gå ett steg i taget för i i loopen för en sträng men du vill ändå kontrollera i+1 och i+2. Ja, innan detta vill du också kolla att strängen som kontrolleras är åtminstone tre tecken lång!😉
Och går vi ned på lite detaljer så blir det lite som att nästan varje algoritmmönster (en funktion som gör något med något mottaget argument i sin parameter och sedan returnerar ett värde) har följande komponenter pga. hur kod måste skrivas för att kunna kompileras/tolkas till maskinkod:
- Variabeln som innehåller argumentet eller variablerna för argumenten
- Initierad returvariabel som returneras via retursatsen
- Tillfälliga variabler som behövs för att kunna bearbeta argumentvariablerna
- En eller flera kontrollflöden (t.ex. loop-,while-satser, och/eller if-elseif-else-satser)
- I vissa fall går det att köra "en lång kedjad one-liner" (se vissa Advent of Code-lösningar)
Å ena sidan är detta rätt så "meh.... duh???!". Å andra sidan så tycker jag att detta är något som borde på något vis tas upp tidigt i kurserna om programmering för att nöta som bra riktlinjer. Du får data/bytes som du vill kunna bearbeta på något vis för att kunna returnera antingen ny eller ändrar data. Det sistnämnda fallet innebär referens som t.ex. &$variabel i PHP.
För att kunna bearbeta data du tagit emot så behöver du på något vis "representera" hur du ska bearbeta all data. I fallet med Fibonacci-numren så behövde jag "representera" två redan färdiga Fibonacci-nummer för att sedan kunna använda dessa för att skapa nästa Fibonacci-nummer tills att det önskade kunde hittas och därmed skickas tillbaka i retursatsen där returvariabeln fanns.
Av någon anledning så hade jag inte dessa riktlinjer införstådda i mig under min Webbutvecklingsutbildning utan det blev snarare något som jag kom på i efterhand med erfarenhet, nöta YT-klipp, nöta allmän info om programmering, läsa här på Sweclockers och på diverse andra programmeringssällskap ute på stora vida webben!
Om Du känner till något intressant och/eller vanligt "algoritmmönster" så får du jättehjärna dela med dig! \q[^_^]p/
På återseende!
Mvh,
WKF.
---------
✔️HT2022-VT2024 TWEUG Webbutvecklings-programmet 120hp (distans)
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Senast redigerat
ok-funktionen tillagd
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
100 % CERTIFIED SPAGHETTI CODE Feat. Leif Mannerström
På återseende!
Mvh,
WKF.
---------
✔️HT2022-VT2024 TWEUG Webbutvecklings-programmet 120hp (distans)
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Webbutvecklingsdagbok - efter studierna
Detta blir en kortare uppdatering, med mest fokus på hobbyprojektet: "FunkPHP"-ramverket.
(Så här i efterhand: definiera, "kortare"...) (-_- #) |
OBS: Rättstavningsinsticksmodulen fungerade ej för mig i FireFox när jag skulle korrekturläsa detta. Så Du Vet!🤪
Jobb & Uppdrag
Jag hade möte tidigare denna vecka med tidigare än så länge nöjd Uppdragsgivare och de verkar ha rott i hamn ett referensuppdrag så att de senare kan ansöka om finansiella medel för att anlita mig ett par veckor. Men det återstå att se i och med rådande geoekonomiska tider.
Jag skrev till en person på LinkedIn då denna person frågade om denne kunde ta sig an att göra en mobilapp med hjälp av Vibe Coding (AI-slarvviruset sprider sig allt mer!😂) medan jag då i mitt meddelande argumenterade för en enklare webbapp som prototyp - dvs., att jag gör det som ett enklare och kortare referensuppdrag.
Jag Inväntar fortfarande svar från en annan angående eventuellt 1-2 månaders distansuppdrag inom frontend-utveckling. Förra veckan fick jag inget jobb från Stockholmskund men denna vecka fick jag och det är färdigt nu så att jag kan fokusera på Webbutvecklingsfrilansandet vilket börjar med steg 1 fortfarande: bygga upp något som står ut från mängden bland andra Fullstacks-Junior-Webbutvecklare! 🫡
Hobbyprojekt
Likt inledningar i Nintendo Directs så säger jag nu: Ta först en titt på det här:
<?php // "compiled_route_trie.php"
return [
'GET' => [ // This is "/" level
'users' => [
'|' => [], // Middleware applies at /users level (sibling key)
':' => [
'id' => [],
],
],
'test' => [],
'about' => [],
],
'POST' => [
'users' => [
'|' => [], // Middleware applies at /users level (sibling key)
':' => [
'id' => [],
],
],
],
];
Dold text
Detta är en Trie-datastruktur med två vanliga HTTP-metoder som rotnoderna. Sedan har de tre olika slags "tokens" som tolkas vid varje nivå:
'[a-zA-Z_-0-9]' = Exakt rutt. Exempelvis ser du 'users' vilket betyder rutten "/users" och ja: rutten "/" är antydd genom om du befinner dig först i "GET"-rotnoden. Strängen för begärd rutt blir först i små UTF-8 bokstäver och sedan är det bara att matcha järnet! Andra strängrutter på samma nivå är alltså "/test" och "/about".
':' = Dynamisk rutt-avskiljare. Nästa steg för en rutt är dynamiska rutter vilket inleds med ":" där "ruttmatchningsfunktionen" då inser att, "Jaha, dynamisk rutt på nästa nivå, då tar jag dess nyckelvärde vilket i sin tur blir nyckelvärdet för dess tillhörande värde från den delen i den begärda rutten!". Precis när jag skrev detta så insåg jag att "Vad händer om jag lägger till en ytterligare ':'? Den kraschar inte, och finner en matchning i den kompilerade ruttfilen men inte i utvecklarens rutter då båda måste matcha. (mer om det snart!)
'|' = Middleware-avskiljare. Denna är nog min favorit för vad den helt enkelt indikerar i den kompilerade ruttfilen är att, "Alla ruttsträngar du har lagt till hittills tillhör en middleware-rutt i middleware-ruttfilen för utvecklaren!" (se "middleware_routes.php"-filen) Så då tar den de hittills matchade ruttsegmenten och lagrar i en förberedd array och ställer den sig på '|' som ny nuvarande nod och fortsätter som om ingenting.
Funktionen som sköter allt detta är denna:
<?php // "function r_match_denied_global_uas($denied_uas, $ua)" in "r_route_funs.php"
// Match Compiled Route with URI Segments, used by "r_match_developer_route"
function r_match_compiled_route(string $requestUri, array $methodRootNode): ?array
{
// Prepare & and extract URI Segments and remove empty segments
$path = trim(strtolower($requestUri), '/');
$uriSegments = empty($path) ? [] : array_values(array_filter(explode('/', $path)));
$uriSegmentCount = count($uriSegments);
// Prepare variables to store the current node,
// matched segments, parameters, and middlewares
$currentNode = $methodRootNode;
$matchedPathSegments = [];
$matchedParams = [];
$matchedMiddlewares = [];
$segmentsConsumed = 0;
// EDGE-CASE: '/' and include middleware at root node if it exists
if ($uriSegmentCount === 0) {
if (isset($currentNode['|'])) {
array_push($matchedMiddlewares, "/" . implode('/', $matchedPathSegments));
}
return ["route" => '/', "params" => $matchedParams, "middlewares" => $matchedMiddlewares];
}
// Iterate URI segments when more than 0
for ($i = 0; $i < $uriSegmentCount; $i++) {
$currentUriSegment = $uriSegments[$i];
/// First try match "|" middleware node
if (isset($currentNode['|'])) {
array_push($matchedMiddlewares, "/" . implode('/', $matchedPathSegments));
}
// Then try match literal route
if (isset($currentNode[$currentUriSegment])) {
$matchedPathSegments[] = $currentUriSegment;
$currentNode = $currentNode[$currentUriSegment];
$segmentsConsumed++;
continue;
}
// Or try match dynamic route ":" indicator node and
// only store param and matched URI segment if not null
if (isset($currentNode[':'])) {
$placeholderKey = key($currentNode[':']);
if ($placeholderKey !== null && isset($currentNode[':'][$placeholderKey])) {
$matchedParams[$placeholderKey] = $currentUriSegment;
$matchedPathSegments[] = ":" . $placeholderKey;
$currentNode = $currentNode[':'][$placeholderKey];
$segmentsConsumed++;
continue;
}
}
// No matched "|", ":" or literal route in Compiled Routes!
return null;
}
// EDGE-CASE: Add middleware at last node if it exists
if (isset($currentNode['|'])) {
array_push($matchedMiddlewares, "/" . implode('/', $matchedPathSegments));
}
// Return matched route, params & middlewares
// if all consumed segments matched
if ($segmentsConsumed === $uriSegmentCount) {
if (!empty($matchedPathSegments)) {
return ["route" => '/' . implode('/', $matchedPathSegments), "params" => $matchedParams, "middlewares" => $matchedMiddlewares];
}
// EDGE-CASE: 0 consumed segments
// matched, return null instead of matched
else {
return null;
}
}
// EDGE-CASES: Return null when impossible(?)/unexpected behavior
else {
return null;
}
return null;
}
Dold text
Funktionen har på ett ungefär O(n) där n är antalet URI-segment att matcha mot. Och det jag personligen är stolt över - även om Go-webbservrar får PHP-servrar att framstå som snigelservrar - är faktumet att den kan skapa tre saker samtidigt under tiden:
1) Matchad rutt i den kompilerade ruttfilen.
2) Matchade middlewares som också kan köras sedan i rätt ordning.
3) Matchade och extraherade dynamiska rutterparametrar.
(Rolig notis: Jag velade fram och tillbaka om jag skulle köra {id} eller :id och jag valde det sistnämnda för att spara en byte för varje implementering! Jag inbillar mig också att: "$matchedPathSegments[] = ":" . $placeholderKey;" är snabbare än att köra "substr($placeholderKey,1,-1);" p åsamma variabel för att associera nyckelvärdet med nyckelnamnet!)
En trevlig bonus är att den har väldigt svårt för att krascha. Snarare kraschar kraschar du först servern genom att skicka ogiltiga tecken i HTTP-anropet.
En anledning till varför den inte kan krascha riktigt är för att går bara så djupt som antalet URI-segment det finns, det vill säga för varje "/". Och skulle du skicka något i stil med "/users/10////" så kommer den att ta bort överflödet av skiljetecknen och även beroende på konfigurerad webbserver så kan andra säkerhetsåtgärder vidtas.
Den andra anledningen är att när den nu vet hur många segment den får iterera igenom så kan den antingen gå tillräckligt djupt i Trie-strukturen tills den får slut på segment eller tills att den inte hittar nästa segment i Trie-strukturen. Antingen hittar den en matchning eller inte.
Och ja, specialfallet när du bara navigerar till bara "/" är hanterat inklusive specialfallet när du vill ha en '|'-middleware direkt i rotnoden såväl som i slutet av den sista matchande noden i Trie-strukturen och inga fler URI-segment finns kvar att matcha!
Vänligen ta nu en titt på dessa två filer:
<?php // "single_routes.php"
return [
'GET' => [
'/users' => ['handler' => 'USERS_PAGE', /*...*/],
'/users/:id' => ['handler' => 'USER_ID_PAGE', /*...*/],
'/about' => ['handler' => 'ABOUT_PAGE', /*...*/],
],
'POST' => [
'/users' => ['handler' => 'post_create_user', /*...*/],
'/users/:id' => ['handler' => 'post_update_user', /*...*/],
],
'PUT' => [
'/users/:id' => ['handler' => 'put_update_user', /*...*/],
],
'DELETE' => [
'/users/:id' => ['handler' => 'delete_delete_user', /*...*/],
],
];
Dold text
<?php // "middleware_routes.php"
return [
'GET' => [
'/' => ['handler' => 'GET_CHECK_CONTENT_TYPE', /*...*/],
'/users' => ['handler' => ['GET_VALIDATE_USER_IP', 'GET_VALIDATE_USER_AU'], /*...*/],
'/users/:id' => ['handler' => 'GET_MIDDLEWARE_USER_ID', /*...*/],
],
'POST' => [
'/users' => ['handler' => 'POST_MIDDLEWARE_USER', /*...*/],
'/users/:id' => ['handler' => 'POST_MIDDLEWARE_USER_PROFILE_TEST', /*...*/],
],
'PUT' => [
'/users/:id' => ['handler' => 'PUT_MIDDLEWARE_USER', /*...*/],
],
'DELETE' => [
'/users/:id' => ['handler' => 'DELETE_MIDDLEWARE_USER', /*...*/],
],
];
Dold text
Dessa två är alltså filerna där Utvecklaren måste hårdkoda in enskilda rutter såväl som mellanrutterna (eng. middlewares). En detalj jag älskar här är att mellanrutterna kommer före singelrutterna både i filhanteringen i mappen där de ligger såväl som i hur Utvecklaren bör skriva dem.
Om du jämför mellanrutterna mot singelrutterna så ser du en intressant detalj i denna:
[GET => ['/users' => ['handler' => ['GET_VALIDATE_USER_IP', 'GET_VALIDATE_USER_AU'], /*...*/]];
Den har alltså två stycken inuti handler-nyckeln medan övriga bara har en. Hur Utvecklaren väljer att implementera dessa är upp till denne. Det smidiga är att mellanrutterna med kortare ruttsträng kommer att hamna först i arrayen som innehåller alla matchade mellanrutter!
På så vis kan du ha en autentiseringsrutt för "/users/" som då kan köras före de övriga i en logisk ordning. Eller ja, ¯\_(ツ)_/¯ , du kan ju lika gärna bara anropa den mellanruttsfunktion som du vet att du vill köra först bara du vet vart den är i arrayen. Se det lite mer som en QoL-implementering.
För att testköra rutterna så går det att ta en titt på "funkphp_start.php" vilket är filen som körs för alla omdirigerade HTTP-anrop:
<?php // ENTRY POINT OF EACH HTTPS REQUEST thanks to ".htaccess" file
include_once __DIR__ . '/_internals/functions/_includeAll.php';
include_once __DIR__ . '/dx_steps/_includeAll.php';
//REMOVE AFTER TESTING!
// echo "User IP:'" . $req['ip'] . "'<br> ";
// echo "User URI:'" . $req['uri'] . "'<br> ";
// echo "User Query: " . $req['query'] . "<br> <br>";
// Load configurations and global variables
$fphp_global_config = h_load_config($fphp_all_global_variables_as_strings);
if (!ok($fphp_global_config)) {
return_code(418);
exit;
}
// Developer's route definitions
// Middlwares
$developerMiddleRoutes = include __DIR__ . '/routes/middleware_routes.php';
// Singles
$developerSingleRoutes = include __DIR__ . '/routes/single_routes.php';
// Compiled Trie structure where "#" indicates dynamic route and "|" indicates middleware
$compiledTrie = include __DIR__ . '/_internals/compiled_route_trie.php';
// --- Test Cases ---
echo json_encode(r_match_developer_route($req['method'], $req['uri'], $compiledTrie, $developerSingleRoutes, $developerMiddleRoutes), JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES);
Dold text
En sak jag lärde mig då vilket jag skäms över att jag inte fattat och använt innan är att du kan inkludera returvärden direkt i variabler när du använder "include"-direktivet i PHP!? (－‸ლ) 🤦♂️ Detta fick jag veta av Gemini 2.5 Pro vilket jag använt mig av för att kunna förstå all kod jag har använt mig av.
Den gav mig först en bra start men det var jag personligen som upptäckte, insåg och sedan fixade de olika specialfallen. I takt med det så blev jag också mer insatt i flödet och vissa gånger så förstörde Gemini 2.5 Pro min kod som jag ej höll med men det var ju bara att ignorera så.
Nu ser du så klart funktionen "r_match_developer_route" vilket är något helt annat vilket avslöjas enligt nedan:
<?php // FUNCTION FROM: "r_route_funs.php"
function r_match_developer_route(string $method, string $uri, array $compiledTrie, array $developerSingleRoutes, array $developerMiddlewareRoutes, string $handlerKey = "handler", string $mHandlerKey = "handler")
{
// Prepare return values
$matchedRoute = null;
$matchedRouteHandler = null;
$matchedRouteParams = null;
$matchedMiddlewareHandlers = [];
$routeDefinition = null;
$noMatchIn = ""; // Use as debug value
// Try match HTTP Method Key in Compiled Routes
if (isset($compiledTrie[$method])) {
$routeDefinition = r_match_compiled_route($uri, $compiledTrie[$method]);
} else {
$noMatchIn = "COMPILED_ROUTE_KEY (" . mb_strtoupper($method) . ") & ";
}
// When Matched Compiled Route, try match Developer's defined route
if ($routeDefinition !== null) {
$matchedRoute = $routeDefinition["route"];
$matchedRouteParams = $routeDefinition["params"] ?? null;
// If Compiled Route Matches Developers Defined Route!
if (isset($developerSingleRoutes[$method][$routeDefinition["route"]])) {
$routeInfo = $developerSingleRoutes[$method][$routeDefinition["route"]];
$matchedRouteHandler = $routeInfo[$handlerKey] ?? null;
$noMatchIn = "BOTH_MATCHED";
// Add Any Matched Middlewares Handlers Defined By Developer
if (
isset($routeDefinition["middlewares"]) && !empty($routeDefinition["middlewares"] && is_array($routeDefinition["middlewares"]))
) {
foreach ($routeDefinition["middlewares"] as $middleware) {
if (isset($developerMiddlewareRoutes[$method][$middleware]) && isset($developerMiddlewareRoutes[$method][$middleware][$mHandlerKey])) {
$matchedMiddlewareHandlers[] = $developerMiddlewareRoutes[$method][$middleware][$mHandlerKey] ?? null;
}
}
}
} else {
$noMatchIn .= "DEVELOPER_SINGLE_ROUTES";
}
} else {
$noMatchIn .= "COMPILED_ROUTES";
}
return [
"route" => $matchedRoute,
"$handlerKey" => $matchedRouteHandler,
"params" => $matchedRouteParams,
"middlewares" => $matchedMiddlewareHandlers,
"no_match_in" => $noMatchIn, // Use as debug value
];
}
Dold text
Det är den där funktionen som först anropar matchningsfunktionen mot den kompilerade Trie-strukturfilen (eller ja, returvärdet i en variabel i detta fall). Sedan när den får tillbaka något värde (även null) så returnerar den en associativ array med matnyttiga variabler för att nyttja (se bild nedan):
I svarsobjektet syns exempelanvändning av en anropad rutt lokalt och hur parametrarna ur den dynamiska delen har extraherats, rätt matchad rutt finns att nyttja, dess "handler" (och du kan döpa om det där nyckelnamnet vid varje funktionsanrop om du vore så Frisk & Galen™), mellanruttarna och en sak som får en att ta sig om sin nyrakade haka:🤔
"no_match_in": "BOTH_MATCHED"
Det där är endast ett "debugvärde" vilket även står i kommentaren i slutet av funktionen. Tanken är att om du skulle ha skrivit fel så kommer du internt (ej i produktion, förhoppningsvis!) att få se en sträng som säger om det är den kompilerade ruttfilen som ej matchade eller Utvecklarens egna singelruttar.
Samtidigt kan det ju också användas för att genomföra mer komplex matchning om första matchningen skulle misslyckas? I slutändan är allt detta enbart två funktioner och några filer med (mellan)rutterna och en fil dit alla HTTP-anrop kan omdirigeras till via en .htaccess-fil.
En självkritisk sak ska nämnas och jag kunde inte få något vettigt ur Gemini 2.5 Pro tills att jag fick slut på gratisanvändningen av den och det berör så kallada Adaptiva Trie-datastrukturer. Exempelvis skulle vissa rutter i den kompilerade ruttfilen slås ihop men hur ska det kontrolleras utan att behöva göra intensiv strängbearbetning än den HashTable Lookup-elegans den gör just nu?! 😵
Om till exempelvis hypotesrutten "/blog" bara har underutten "/posts" så skulle båda kunna slås ihop till "blog/posts". Utmaningen då är att det skulle innebära att kika inuti varje nod om den innehåller ett "/" alternativt dela upp URI-segmenten till inte bara enskilda segment utan också parsegment så att "blog/posts" då skulle bli ett. Men då skulle vi behöva göra en ytterligare kontrollmatchning och frågan är hur mycket vi vinner på det hela genom att bara ha en ytterligare HashTable Lookup för att spara några bytes varje gång det tillämpas i den kompilerade ruttfilen?
Nåja, det är bättre än ingenting och i takt med hundratals eller till och med tusentals rutter så blir foreach inte lämplig utan detta har varit några dagars mycket givande tillfälle att nöta YT-klipp, kika i artiklar samt tagit hjälp av gratis LLM:er för att förstå mig på Trie-datastrukturer på en mycket grundläggande nivå.
Dessa går även att applicera till att begränsa olika omfång av IP-adresser t.ex. matcha mot "80.XXX.Y" där X matchar endas nästa 0-9 siffra exakt medan Y innebär matcha resten av IP-strängen. Här gäller det att vara försiktig så att man inte råkar låsa ute nästan hela sin användarbas på grund av ett felplacerat Y i en Trie-datastruktur!🤣
Avslutningsvis för denna gång så är detta bara platshållartext:
<br>YOU SHOULD NOT SEE THIS! SO ERROR!<br>
Den indikerar att du har nått slutet av PHP-filen som ska hantera alla HTTP-anrop och där får det läggas in något standardsvar, vare sig det är HTTP-svarskod 418 eller kanske en ASCII-bild på en glad pingvin? 🐧
Vidareutbildning
Inget nytt att rapportera förutom att jag snart har lärt mig grunderna i att applicera Trie-datastrukturer i praktiken!
På återseende!
Mvh,
WKF.
---------
✔️HT2022-VT2024 TWEUG Webbutvecklings-programmet 120hp (distans)
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Webbutvecklingsdagbok - efter studierna
VARNING: Detta inlägg och möjligen nästa innehåller en gigantisk uppdatering av hobbyprojektet FunkPHP-ramverket - det 99 % funktionsbaserade ramverket helt i PHP!
Jobb & Uppdrag
Igår fick jag en jättelast av jobb från Stockholmskunden och jag betade av ett par igår. Jag fortsätter med att beta av resterande efter att jag har skrivit detta och eventuellt ett ytterligare inlägg på rad redan samma dag! 🤯
Kortfattad uppdatering här är att imorgon den 17:e april 2025 ska jag delta i Indiehackers videogruppträff och den 28:e april 2025 kommer jag att delta i en så kallad Dragon Tech-lunchträff med helt okända men teknikinsatta människor.
Frågan är om jag på något vis skulle kunna visa upp mitt 99 % funktionsbaserade PHP-ramverk då samtidigt som jag också lyfter fram att jag är "färsking" inom Webbutvecklingsmarknaden som nyutexaminerad sedan maj 2024? 🤔
Nu vidare till vad som är del 1 av 2 delar under samma dag!
Hobbyprojekt
Se Figur 1 (bilden nedan) så ser du det allmänna flödesschemat för FunkPHP för varje inkommen HTTP-förfrågan:
Stegen omfattar följande exekvering i den ordning de beskrivs nedan:
Kontrollera först om detta är rätt steg och kör i sådana fall allt inuti kodsatsen och avsluta den med att sätta nästa steg. Ladda in den globala $c-variabeln (vissa kodarkitekturerskulle kalla denna för "context variable") där i princip allt finns gällande HTTP-förfrågan, matchade (dynamiska) rutter, erhållna databasdata samt sida att returnera om inte JSON redan returnerades (ja, så API-stöd finns). Allt laddas inte in samtidigt för - förhoppningsvis - optimal prestanda. Här omdirigeras även förfrågan om den ej är i HTTPS. Sessionskakans parametrar sätts, databasanslutning anropas och lagras i $c['db'] med anslutet databasanslutningsobjekt eller null, säkra svarshuvuden (eng. "headers") sätts och osäkra sådana raderas (t.ex. "Server", "X-Powered-By". Sedan förbereds och lagras en förberedd URI-sträng via:$c['req']['uri'] = r_prepare_uri($_SERVER['REQUEST_URI'], $c['BASEURLS']['BASEURL_URI']); Till sist i steg 1: $c['req']['next_step'] = 1;. Det sistnämnda är vedertaget för övriga steg förutom det sista/sjätte steget!
Kontrollera steg och kör kodsats om rätt steg. Avsluta med sätta nästa steg. Tre funktioner: r_match_denied_methods();, r_match_denied_exact_ips(); och r_match_denied_uas_fast();
Kontrollera och kör endast rätt steg. Sätt alltid nästa steg. Ladda in kompilerade, singel- och mellanrutter via $c['ROUTES'] = [...];. Matcha mot giltig rutt r_match_developer_route(); och lagra sedan i $c['req'].
Start enligt föregående steg. Om det fanns mellanruttskod (eng. "middleware code") till matchande rutt så kör dem i den ordning de lades till av Utvecklaren under utveckling. INFO: Detta steg kommer troligtvis att slås ihop med föregående steg så att det sammanlagt blir fem steg i slutändan!
Start enligt föregående steg. Ladda in kompilerade, singel- och mellanrutterna för datasteget i $c['ROUTES']['DATA']. Matcha med: d_match_developer_data_route();. Om det finns ej ännu körda mellanrutter från föregående matchningssteg så slå ihop arrayerna, annars lägg bara till. Lagra övriga datastegsrelevanta data i och med matchningsfunktionen. TODO: Än så länge körs inte mellanruttskoden förknippad med datasteget, men det implementeras troligen mycket snart!™
Start enligt föregående steg förutom inget nytt nästa steg att sätta i slutet av kodsatsen! Ladda in kompilerade, singel- och mellanrutter för sidorna (det motsvarande till "views/vyer") i: $c['ROUTES']['PAGE'] = [...]. Matcha med p_match_developer_page_route(); - ej implementerad/skriven ännu - och lagra nödvändiga sidstegsrelevanta data i och med den snart™ skrivna matchningsfunktionen. Avsluta det hela med att returnera en sida/vy och/eller köra förknippad mellanruttskod. TODO: Än så länge körs inte mellanruttskoden förknippad med sidsteget, men det implementeras troligen mycket snart!™
De sex stegen - (deras stegfiler - i skrivande stund - ligger i dx_steps) - ovan kompletteras med bilden nedan som visar den allmänna mappstrukturen i ett FunkPHP-projekt där det mesta liknar klassiska MVC förutom att "Models" heter "data" och "Views" numera heter "pages":
En sak jag lyckades få till efter jag läst och tittat på YT-klipp om datastrukturen Trie (ej Radix dock!) är vad som illustreras i bilden nedan:
Notera följande utdrag ur den associativa arrayen:
return 'GET' =>['users' => [':' => ['id' => ['test' => ['|' => [],], '|' => [],],],],];
(Rolig skrivincidens: Jag råkade skriva om troute_route.php-filen vilket har annorlunda struktur så fick skriva om!)
GET innebär anropsmetoden, medan varje "nyckeldjup" (arraynyckeln inuti) innebär rutt delat med ett "/". Men vänta...! (som resonerande LLM:er säger) Vad är ":" och vad sjutton är "|" i detta ruttutdrag?
Det förstnämnda indikerar för matchningsfunktionen att det nästa efter en ny "/" (eftersom vi gick ett ytterligare nyckeldjup) är en dynamisk rutt så du (matchningsfunktionen) ska tolka detta som giltig matchning och bara gå vidare till nästa nyckeldjup "/".
Vad händer då när nästa nyckeldjup är "|"? |-nyckeln säger till matchningsfunktionen att här går skiljelinjen för mellanruttskoder lagrade i mellanruttsfilen att köra. När |-nyckeln ligger på samma nivå så innebär det specialfallet när du har mellanruttskod för exempelvis GET/. Du kanske även ser i bilden att en |-nyckel ligger på samma nivå som GET/users/:id/test?
Här hanteras två specialfall: Du navigerade till GET/ som har tillhörande mellanruttskod eller du navigerade till sista nyckeldjupet och det finns en |-nyckel där som du inte kontrollerat för i och med att du gått igenom alla "/"-segment:
// Från: /src/funkphp/_internals/functions/r_route_funs.php - r_match_compiled_route();
// EDGE-CASE: Add middleware at last node if it exists
if (isset($currentNode['|'])) {array_push($matchedMiddlewares, "/" . implode('/', $matchedPathSegments));}
Det fungerar - än så länge - förvånansvärt bra och då stegen för rutt, data och sidor kan ha helt olika mellanrutter förknippade med dem så har de också sina egna kompilerade Trie-datastrukturer i src/funkphp/_internals/compiled/.
Bilden nedan visar hur du kan ha helt andra rutter i exempelvis ruttmatchningssteget (steg 3) jämfört med vilka förknippade rutter som finns i datasteget (steg 5 - ja, du "hör" nu hur skumt detta kan låta; det blir troligen att slå ihop vissa steg och inte börja räkna från noll dessutom i filerna! 😂):
Fast vänta nu... Detta låter motsägelsefullt: Anta att vi har en rutt GET/users/:id men ingen djupare än så för GET/users. Hur kan det då finnas en mellanrutt (vilket bara kan köras om själva singelrutten först matchas!) i nästa steg? Den kommer ju aldrig att matchas i singelrutten till att börja med och då tar den onödig textplats och dessutom förvirrar utvecklaren!
Hur kan vi konsekvent lägga till singel- och mellanrutter med ett enkelt klick? Klick blir nog svårt... Vad sägs om att bara kunna skriva i något slags skräddarsytt CLI som kommer med när du klonar repot? 🖵
Tillåt mig få introducera FunkCLI och om du tittar i första bilden i detta första inlägg av två delar så kommer du att se en fil utan filtyp som heter inte mer eller mindre än självaste FunKCLI! Den ska vi ta en närmare titt på i nästa andra del av detta inlägg som är uppdelat i två delar så att säga! 🫡
Fortsättning följer direkt i nästa inlägg efter detta! Här: #20841913
Mvh,
WKF.
---------
✔️HT2022-VT2024 TWEUG Webbutvecklings-programmet 120hp (distans)
Senast redigerat
Lagt till fortsättningslänk
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Webbutvecklingsdagbok - efter studierna
Hobbyprojekt (fortsättning från: #20841909 )
Ta först en titt på de tillgängliga funktionerna relaterade till FunkCLI:
Du har funktioner för att kunna:
- Kompilera rutter. [/i](skapa den så kallade Trie-strukturen)[/i]
- Skapa filer av kompilerade rutter. (skapa filerna i src/funkphp/_internals/compiled/-mappen)
- Säkerhetsgranska alla rutter innan de ens får kompileras. (EJ SKRIVEN ÄNNU!!!)
- Konvertera fula och äckliga PHP-arrays() till eleganta PHP-arrays[]. (den används för att du inte ska se array() överallt i Trie-filerna vilket sparar på utrymme, men säkert lika svårläst)
- Flera funktioner för att i vald Terminal konsekvent visa olika färger och textmeddelanden beroende på typ av händelse: ogiltigt syntax, giltigt kommando fick fel vid körning i röd text, giltigt kommando lyckades köras i grön text, information om något i blå text, info om något över flera rader i blå text (anropa alltså den flera gånger i följd och avsluta manuellt med exit;) och avslutningsvis kan varning skrivas ut i röd text.
Hur ser då starten ut för FunkCLI? Jo, så här ser det ut först i början:
Sedan behövs det ju en bra struktur för att lättsamt kunna lägga till nya kommandon. Tack vare Trie-datastrukturtänkandet där du vill uppnå O(1) så tänkte jag något, skrev lite och sedan skickade vidare till Gemini 2.0 Thinking Version vilket då gav mig den mycket eleganta och O(1)-vänliga strukturen enligt bilden nedan:
(ja, jag ser "NAJS"-felet på rad 69 och det är redan åtgärdat när du läser detta!)
I bilden ovan får du exempel på när flerradsfunktionen används för att skriva ut och manuellt avsluta skriptet. Du ser även "add", "change", "delete" och "help" nedan där endast "help" är implementerat. De övriga kommer sedan och det är dessa som kommer att göra FunkPHP faktiskt användarvänligt.
Istället för att du manuellt ska komma ihåg om du matat in samma rutt i alla steg (routes, data, pages) så ska du bara behöva skriva något i stil med följande i din PHP-kompatibla terminal:
php funkcli add route GET/rutt/:underrutt/ mws:log,auth
Terminalkommandot ovan ska då skapa en rutt som heter /rutt/:underrutt under GET-nyckeln och sedan två tillhörande mellanruttsfiler: log och auth. Standardbeteendet här - efter vedertagen datavalidering av kommandots olika argument - kommer bli att alla tre troute-filer kommer att få samma /rutt/:underrutt under respektive GET-nyckel men bara routes/route_middleware_routes.php-fil kommer att få mellanrutterna log och auth till sin GET/rutt/:underrutt/.
Självfallet kommer även information att ges om det redan finns rutter och du meddelas även om att när det lyckats så måste du manuellt lägga till eventuella mellanrutter till data och pages för den tillagda GET/rutt/:underrutt. En sak du kanske funderar nu på eftersom det handlar om att manipulera filer lokalt är: Vad ska hända vid change och/eller delete?
Det har jag tänkt på: Eftersom change och delete kan betraktas som destruktivt och misstag kan inträffa (exempelvis radera helt fel rutt och därmed all förknippad information vilket kan vara plågsamt att få tillbaka) så kommer dessa kommandon givetvis att skapa säkerhetskopieringar i en undermapp som jag nyss lade till (i skrivande stund(!)) - src/funkphp/_BACKUPS/ - med stora bokstäver så Utvecklaren klart och tydligt ser vart det kan finnas säkerhetskopieringar av olika slags.
Då filerna kommer att vara datumbaserade i filnamnets slut: FILNAMN-YYYY_MM_DD_HH_MM_SS.php så kommer det ju gå att skriva funktioner såsom restore som kan återställa den senaste filen så du i princip får ett "Ångra"-kommando rakt i ditt FunkCLI!
"Vänta nu här Herr Färsking_Till_FullStacksWebbJunior! Hur tänker du nu? Vad händer med filen som återställts då och vad händer om återställningen i sig är ett rent och skärt misstag?" Därför finns det redan en sista utväg: /src/funkphp/_BACKUPS/_FINAL_BACKUPS/ där då allt i princip skulle kunna läggas förutsatt att Utvecklaren är medveten om påfrestningen det kan ha på operativsystemets I/O-hantering och/eller själva lagringsutrymmet i sig.
Ja, just det: Jag glömde visa dig sista delen i FunkCLI:
Här lagras då först kommandona och saknas det tredje argumentet - $argv[2] - eller är null så körs kommandon som ej tar något argument som exempelvis php funkcli help. Övriga funktioner som kan ta flera argument utöver sina (sub)kommandon kan hantera sin datavalidering där istället för här längst ned i CLI-skriptet.
Det finns en viktig sak som FunkCLI löser förutom att göra det bekvämt för Utvecklaren och för att någon ens kanske skulle orka vilja prova på FunkPHP med tanke på det vardagliga memes såsom: "Baby, wake up, another JS Framework just dropped, KEKW!!!".
Vad den löser är min första tanke med gui-mappen då jag tänkte att det behövdes något mer för att kunna stå ut från mängden av alla existerande ramverk idag, vare sig det är JS, PHP eller något annat. PHP Laravel har ju exempelvis php artisan och jag FunkCLI uppstod som följd av att jag ville bannemig kunna "få till" något liknande även om det kanske inte nödvändigtvis någonsin kommer att bli lika omfattande och/eller komplext? 🤔
Ett GUI vore 420 % mer fräckt att ha och kunna visa upp som portfölj men då jag inte primärt är frontend-lagd så anser jag att det är fel väg att försöka gå med detta hobbyprojekt. Planen är sedan att jag faktiskt själv kommer att använda detta FunkPHP-ramverk till ett par av mina enklare webbplatser.
Det sista jag för denna gång vill nämna om FunkPHP är att det kommer att "lanseras" med följande inkluderade mellanruttskoder så det snabbt går att nyttja autentisering och/eller auktorisering:
- MW_R_AUTH_ONLY_COOKIES.php
- MW_R_AUTH_ONLY_DB.php
- MW_R_AUTH_COOKIES_AND_DB.php
Så var är då:"MW_R_AUTH_ONLY_JWT.php" och "MW_R_AUTH_JWT_AND_DB.php" någonstans? Självfallet vore det rejäl hybris att jag skulle kunna lansera något skräddarsytt som kräver mycket exakt hantering av JSONWebTokens när det gäller skapande, signering, såväl som verifiering. Där saknar jag den nödvändiga förståelsen i den utsträckning jag behöver förstå den för att kunna använda på vedertaget vis enligt bäst branschpraxis.
(Jag använder ju beprövade PHP-funktioner som password_hash(), verify_password() och sodium_compare() vid behov istället för att tro att jag kan skriva några egna kryptobaserade funktioner som ska korrekt ha entropi, vara kvantsäkert, såväl som kunna stå emot så kallade timing-attacker!)
Avslutningsvis för denna gång så vill jag säga att en sak jag insåg med det första utkastet av FunkCLI är att jag förstår nu varför många hyllar textterminaler framför läckra men kanske också samtidigt mycket komplexa grafiska användargränssnitt.
Om du - i fallet med FunkPHP när du klonat repot - ska lägga till tre rutter vilket då ska skrivas i tre olika filer samt kompileras om med säkerhetskopior i fall du ångrar dig eller något gick snett, så är det ju mycket mer angeläget att bara kunna skriva ett kort kommando så allt detta sköter sig själv och så får du info om allt som lyckades såväl som allt som misslyckades och antingen provar du igen men lite annorlunda eller bara öppnar ett Issue i mitt repo!😅😬
Vidareutbildning
Inget nytt att rapportera förutom att jag har lärt mig att skriva CLI:er i PHP som går att köra i VS Code Terminal förutsatt att PATH System-variabeln till PHP-tolken är korrekt konfigurerad.
På återseende!
Mvh,
WKF.
---------
✔️HT2022-VT2024 TWEUG Webbutvecklings-programmet 120hp (distans)
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Webbutvecklingsdagbok - efter studierna
Jobb & Uppdrag
Det första referensuppdraget!🫡
Nu på måndag kommer jag att ha vedertaget videomarknadsmöte med den än så länge nöjda Uppdragsgivaren sedan jag tog examen för snart ett år sedan (maj 2024). Denna Uppdragsgivare har äntligen hittat ett referensuppdrag där de då tillsammans med sin slutkund kommer att få prova den webbutvecklade webbappen jag tog fram för snart ett år sedan!
En stark fördel denna Uppdragsgivare beskriver om detta referensuppdrag är att slutkundens slutanvändare i detta fall är mycket mobilvana så då blir det bra testkörning av webbappen som är mobilanpassad trots att det inte är en reell mobilapp i sig. Förhoppningsvis kommer inte Loopias servrar att haverera för att ett dussintal(?) användare anropar PHP-webbplatsen och dess MariaDB-databas?🤔
Inget nytt veckovis jobb men kanske en helt sprillans ny arbetsplats?!🤯
Det blev inget jobb alls denna vecka från Stockholmskunden och jag har inte fått något svar från tidigare uppdragstips som annars skulle ha kommit någon gång i april i år.
Antingen rann det ut i sanden på grund av rådande omvärldsomständigheter och/eller så valdes någon annan framför mig. Som tur var samtidigt denna vecka har jag varit på en fysisk teknikträff nere på stan där jag då fick en idé.
Det är så att vid dessa fysiska teknikträffar så får teknikintresserade presentera/visa upp nästan vadsomhelst teknikrelaterat oavsett hur simpelt eller komplext det må vara så länge det är SFW såklart!😬
Min idé är då att presentera det 99 % funktionsbaserade PHP-ramverket FunkPHP om en månad eller så för att på så vis stå ut från mängden bland nyutexaminerade med minimal arbetslivserfarenhet inom Webbutveckling sedan avslutade studier.
I samma veva vid samma fysiska teknikträff så träffade jag en person som inte bara lyssnar på samma utvecklingsinriktade podcast som jag utan också har samma chef sedan förra gången jag träffade honom under liknande omständigheter. Personen berättade att en person har sagt upp sig vid deras arbetsplats och att de inte har rekryterat någon ny ännu.
Jag bad honom då att kontakta sin chef för att tipsa om att jag finns tillgänglig till ett mycket attraktivt (och troligen "föraktat") arvode som våghalsig IT-frilanskonsult redan direkt efter avslutade studier från maj 2024!😅
Det återstå att se hur det blir av med den saken. Jag går in med låga förväntningar/förhoppningar men är redo att kanske äntligen få in foten bokstavligen talat på någon fysisk arbetsplats nära där jag bor nu när jag har en 100 % (till skillnad från 99 % funktionsbaserad🤭) fungerande cykel sedan någon månad tillbaka.
Hobbyprojekt
Har jag egentligen varit "dum-i-huvudet" i över en månad nu?🤔
På tal om det 99 % funktionsbaserade PHP-ramverket som ska få mig att stå ut från mängden av annars kanske "likvärdigt erfarna juniorer" (å andra sidan går det att kritisera det hela med faktumet att jag inte ägnat tid att lära mig ReactJS, Java, eller annat efterfrågat - så hur "smart" har jag egentligen varit på senaste tid?) så har jag nytt att rapportera.
Jag har ägnat några få tals veckor på FunkPHP-ramverket och det hela började först med att dela in varje HTTP-anropsflöde i tre steg efter vedertagen filtrering av HTTP-metoder, IP-adresser och Användaragenter:
1) Matcha ruttrutt och kör sedan mellanmjukvara
2) Matcha datarutt och kör sedan ytterligare mellanmjukvara
3) Matcha sidrutt och kör sedan ytterligare mellanmjukvara
I takt med att jag skapade dessa och först tyckte att det var häftigt och framförallt komplext så kom mycket snart verkligheten i kapp mig: Det var inte så roligt när det började bli så komplext med att ha relativt upprepade funktioner för alla tre samma steg.
Dessutom började frågor väckas inom mig vilket jag då till slut insåg att om jag upplever dessa väckande frågor, hur lär inte slutanvändarna reagera? Dvs., Utvecklare som otroligt nog skulle få för sig att prova på FunkPHP.
Att först gå in i en fil för att skriva in en rutt att matcha och sedan behöva skriva in samma rutt igen för att matcha "datarutt"(och vad menas ens med att matcha mot en datarutt om vi redan har matchat mot en rutt i ruttrutten?!😵💫)...
...och sedan ska vi upprepa samma sak i rutterna för sidorna? Och det sistnämnda, vad innebär det om vi skulle vilja returnera JSON istället för att kanske tro att vi är tvingade att alltid behöva returerna en förrenderad HTML-sida?🤔
Dessa frågor som börja krypa upp till mitt medvetna i takt med mer komplex kod (några tusentals rader nästan) för att åstadkomma rätt så lite ännu såsom att bara matcha rätt rutter och också ta bort rätt rutter fick mig att inse att det behövdes en drastisk förändring.
Om inte ens jag orkar - som har suttit längst med FunkPHP - pallar med att skriva in samma rutt tre gånger och även inte veta om jag glömt det någonstans eller veta hur de egentligen är tänkta att användas så lär knappast någon som ser det hela för allra första gången palla med det.
Det blir som om Du surfar in på en webbplats med för mycket uppmärksamhetssökande innehåll och du bara tänker reflexivt, "Nepp!" och klickar bakåt.
Således tog jag bort någon tusentals rad kod vilket var mest bara för att kunna lägga till och ta bort rutter utan motsägelsefulla incidenter från de olika tre stegen.
Därmed ledde detta till…
Från onödigt oönskad komplexitet till förhoppningsvis elegant enkelhet!
I bilden nedan ser du nu "troute_route.php" vilket är den Trie-baserade datastrukturen för de inlagda rutter i filen höger om den: "route_single_routes.php" där det sistnämnda filnamnet är kvarlevnaden av att jag först tänkte matcha ruttrutter, sedan datarutter och till sist sidrutter. Hursomhelst så ser du sedan längst till vänster intressanta mappar. Håll gärna utkik på mappen "handlers".
I bilden ovanför kan du se i Terminalen att jag först provat skriva "php funkcli add r g/users" vilket inte gick för du måste ange en hanteringsfil med antingen en hanteringsfunktion eller så blir det en sådan med samma namn som hanteringsfilens namn.
Nästa bild nedanför visar då vad som händer med filerna när du skriver in ett giltigt kommando för att lägga till en giltig rutt med en giltig hanteringsfil med eventuell hanteringsfunktion:
Nu ser du i bilden ovanför hur det har tillkommit en fil "users.php" i handlers-mappen och hur de två tidigare filerna har uppdaterats. Detta beskrivs kortfattat i Terminalen tack vare flitig användning av färgade ekomeddelanden.
Först kontrollerade den att det inte redan fanns en "users.php"-hanteringsfil där hanteringsfunktionen "users" redan användes. Sedan tolkade den rutten "g/users" som "GET/users" (du kan även skriva "GET/users" exakt eller "gEt/users" eller liknande så länge det går att tolka get/, post/, put/ eller delete/ från den).
När alla dessa kontroller gjorts så skapade den hanteringsfilen "users.php" vilket då innehåller hanteringsfunktionen "users". Även filerna med rutterna och den Trie-baserade strukturen över rutterna uppdaterades vilket framgår i Terminalens diverse SUCCESS-rader.
Bilden nedanför här och nu visar sedan hur en ytterligare rutt - GET/users/:id - försökte läggas till men med samma hanteringsfil och hanteringsfunktion "users.php" och "users".
Lägg märke till i bilden ovanför hur detta misslyckades trots att den först sade att "test.php" och "users" är OK såväl som rutten GET/users/:id. Felet beskrivs i SYNTAX ERROR-ekomeddelandet: Hanteringsfunktionen "users" används redan inuti hanteringsfilen "users.php" vilket skapar en konflikt. Hur skulle två olika rutter kunna hanteras av samma hanteringsfunktion?🤔
Visst, skulle det gå ("det mesta går med programmering") men det skulle skapa en möjlig onödigt komplex utvecklingsupplevelse enligt mig eftersom du skulle behöva göra hanteringsfunktionen mer komplex än annars nödvändigt och med tiden kanske du till och från ser två rutter med samma hanteringsfunktionsnamn och du undrar om du gjort ett misstag förrän du kollar upp det. För många onödiga frågor som kan väckas enligt mig!😅
På tal om dessa nästan tjatade hanteringsfiler och hanteringsfunktioner, hur ser de egentligen ut då? Vi har ju den där "handlers/users.php"-filen. Hur ser den ut? Vänligen ta en titt nedan.
Då ser du inuti users.php-filen och hur den har två funktioner. (Tjena, jag igen här! Jag ville bara flika in med det du redan funderat på - ja, du kan INTE välja ett funktionsnamn som redan används av det 99 % funktionsbaserade PHP-ramverket. Tack för mig!)
Först - i bilden ovanför - ser du hanteringsfunktionen users och sedan ser du en funktion vilket är vad som kan anropa den. Lägg också märke till avskiljningskommentarerna vilket hjälper till att i princip CRUDa innehållet i filen. När dessa saknas så kommer felmeddelanden att även fråga Utvecklaren om den försöker jävlas med ramverket!🤣
Du ser också i bilden ovanför att vi nu med kommandot "php funkcli add r g/users/:id users=>by_id" vill lägga till en ny rutt där vi vill lägga till hanteringsfunktionen "by_id" i hanteringsfilen users.php och finns inte users.php i detta fall så kommer den att skapas först.
Således, i bilden nedanför ser du då hur den lades till och hur "users.php" har uppdaterats med den nya hanteringsfunktionen by_id samtidigt som den första users finns kvar utan några som helst problem!
Om du var extra observant i bilden ovan så såg du även hur Trie-strukturen över rutterna såväl som ruttfilen i sig uppdaterades i samband med att vi inte bara lade till en ytterligare hanteringsfunktion utan också en ny rutt. Faktum är att vi lade till en ny rutt med en hanteringsfunktion utifrån en kanske redan existerande hanteringsfil.
Som sagt, finns inte hanteringsfilen så skapas den först och då hade standardanropet i $handler = "users" istället blivit $handler = "by_id" eftersom det blev den första hanteringsfunktionen som lades till i filen. Du skulle då kunna lägga till hanteringsfunktionen users i efterhand.
De två avslutande bilderna visar hur vi först tar bort hanteringsfunktionen "users" ur hanteringsfilen "users.php" med hjälp av terminalkommandot "php funkcli delete r g/users/".
(Ja, du gissade rätt: "r" står för "route" och "h" står för "handler" om du vill använda kortvarianterna av exakt samma terminalkommandon inuti ramverket!)
En sak du kanske reagerar på i första bilden nedanför här är varför troute_route.php-filen inte har uppdaterats men route_single_routes.php-filen har det? Om du skulle gissa. Varför skulle det kunna vara så? En bugg? Eller en "feature"?
Svaret är att det är en "feature" genom att även om du matchar inuti Trie-filen med exempelvis: "GET/users/" så skulle den inte matchas mot något i route_single_routes.php-filen under GET-nyckeln.
Så det specialfallet hanteras redan och möjligen är det istället en positiv bieffekt av hur Trie-strukturen i sig i kombination med algoritmen som använder den som lett till att det möjliga specialfallet "alltid™" hanteras korrekt.
Tar du nu en titt i den nedersta bilden bland de två bilderna ovanför här så ser du till sist hur vi nu äntligen tog bort by_id-hanteringsfunktionen ur users.php-hanteringsfilen.
Jag ritade in i rött för annars kan bilden verka missvisande. När filnamn är struken i VSCode så innebär det att den inte finns kvar i mappen där den låg, dvs., i handlers-mappen i detta fall.
Läs även terminalmeddelandet "Deleted Handler File "users" and Function "by_id"!" längst ned i Terminalfönstret i den nedersta bilden ovan. Dessutom återspeglas det även i hur GET-nyckeln i både Trie-filen såväl som ruttfilen är tom igen!🫡
Hur hög bör man bli på sina egna digitala fisar?
Okej, nu är det dags att tagga ned sin egen "digitala parad"😒 Det hela är både bättre än ingenting och samtidigt kommer det tillbaka till faktumet att: "Varför har du inte lärt dig ReactJS, Java, Kafka, Terraform, Kubernetes, global lastbalansering, Bloom-filtrering, med mera som den riktiga utvecklingsarbetsmarknaden faktiskt efterfrågar?🙄"
Jag säger det där "självelaka" för att inte råka bli hög på min egen digitala fis då jag är både "stolt" över det lilla jag har åstadkommit med den - relativt talat för egen del - stora mängd kod som finns i repot än så länge.
En annan sak jag funderat på som Du kanske skulle vilja hjälpa mig genom att bara lämna ett svar här i tråden är: Vad skulle du ens vilja göra inuti en så kallad "hanteringsfunktion" som matchat mot en given rutt?🤔
Å ena sidan så kan du göra precis allt där eftersom det är ju bara en funktion och så fort du skriver echo eller giltig HTML-kod så börjar du skicka ut HTML-data till klienten som anropat servern.
Detta betyder att detta 99 % funktionsbaserade PHP-ramverk är väldigt "opinionsfritt" i hur du kan välja att använda det. Samtidigt är friheten också en svaghet i sådana slags ramverk enligt mig: Då blir det ju nästan som om du inte förhåller dig inom givna ramar när du skapar ditt verk🤦♂️?
En fördel med så kallade "envisa ramverk" (eng. opinionated frameworks) som exempelvis Angular är att när du hoppar in i ett redan påbörjat projekt så vet du mer eller mindre hur saker och ting kan ha gjorts för att de har behövt hålla sig inom givna ramar när de kodat sina verk.
Om Du själv har åsikter om sådant gällande ramverk allmänt talat och/eller hur det knyter tillbaka till det "mycket avsmalna ramverk" jag håller på att bygga så får du gärna dela med dig här!📝^_^
Vidareutbildning
Inget nytt att rapportera.
På återseende!
Mvh,
WKF.
---------
✔️HT2022-VT2024 TWEUG Webbutvecklings-programmet 120hp (distans)
Senast redigerat
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Webbutvecklingsdagbok - efter studierna
Hallå, någon som fortfarande läser?🤔 Jädrans snålhet att endast visa \d+k utan några decimalpunkter. Allt för att vara mobilanvändarnas stackars smala skärmar till lags!?🤣
Jobb & Uppdrag
Till veckan hoppas jag på vedertaget veckovis jobb från Stockholmskunden såväl som någon form av återkoppling från en person jag träffade vid den fysiska teknikträffen denna vecka.
En annan person som skulle ha hört av sig - som sagt var - någon gång i slutet av april 2025 har ej gjort det ännu så där förmodar jag att det har runnit ut i sanden och/eller att personen funnit en annan utan att ha meddelat mig.
Hobbyprojekt
Typexempel på svagheten/kruxet med funktionell programmering
Det går nu att skapa nycklarna handler, data och middlewares för en given metod/URI-rutt. En sak som inte hade provats ännu var att faktiskt köra de olika hanteringsfunktionerna för respektive testhanteringsfil. Bilden nedanför visar vad jag menar med det hela (det du ser då är lösningen medan jag sedan ska beskriva problemet som inträffade):
Du ser att kommandot - (utgå ifrån att alla kommandon hädanefter börjar med prefixet "php funkcli ") - först är add r g/users users och sedan add d g/users users. Okej, det gör du faktiskt inte för terminalen förstördes när jag minskade bredden för att skärmdumpa. Hursomhelst så ser det ut så här (ryck på axlarna över upprepningen av "Data" här och var - [anmärkning: stavfelet är redan fixat och sjösatt på repot!]):
[FunkCLI - INFO]: Parsed Handler: "funkphp/handlers/r_users.php" and Function: "r_users"
[FunkCLI - INFO]: ROUTE: "g/users" parsed as: "GET/users"
[FunkCLI - SUCCESS]: Added Handler "funkphp/handlers/r_users.php" with Function "r_users" in "funkphp/handlers/r_users.php"!
[FunkCLI - SUCCESS]: Added Route "GET/users" to "funkphp/routes/route_single_routes.php" with Handler "r_users" and Function "r_users"!
[FunkCLI - SUCCESS]: Rebuilt Route file "funkphp/routes/route_single_routes.php"!
[FunkCLI - SUCCESS]: Recompiled Trie Route: "funkphp/_internals/compiled/troute_route.php"!
PS C:\xampp\htdocs\funkphp\src> php funkcli add d g/users users
[FunkCLI - INFO]: Parsed Data Handler: "funkphp/data/d_users.php" and Function: "d_users"
[FunkCLI - INFO]: ROUTE: "g/users" parsed as: "GET/users"
[FunkCLI - SUCCESS]: Added Data Handler "funkphp/data/d_users.php" with Function "d_users" in "funkphp/data/d_users.php"!
[FunkCLI - SUCCESS]: Added Data Data Handler "d_users" and Function "d_users" to Route "GET/users" in "funkphp/routes/route_single_routes.php"!
[FunkCLI - SUCCESS]: Rebuilt Route file "funkphp/routes/route_single_routes.php"!
[FunkCLI - SUCCESS]: Recompiled Trie Route: "funkphp/_internals/compiled/troute_route.php"!
Dold text
Trots att kommandot var först add r g/users users och sedan add r g/users users så skapades: r_users.php respektive d_users.php i handlers respektive data-mapparna. Varför sker det för?
Jo, du gissade helt rätt: med funktioner som körs i det globala omfånget (eng. global scope) så skulle det annars ha inneburit att först kan "test.php" köras men inte nästa "test.php" för det skulle bli omdeklarationsfel av PHP-tolken. Jag missade detta förrän igår när jag faktiskt fick för mig att provköra vardera hanteringsfil för en given rutt för handler- och data-nycklarna.
Det hela löses då med att lägga till ett relevant prefix så som "r_" för handler-nycklar, "d_" för data-nycklar, "m_" för middlewares-nycklar och möjligen "p_" för pages-nycklar. Sistnämnda funderar jag fortfarande på då dessa är tänkt att vara de faktiska HTML-baserade filerna som ska gå igenom en så kallad mallmotor (eng. "template engine") likt Twig från Symphony och/eller Blade från Laravel.
Dessa prefix har också ett litet gulligt långsökt påskägg i sig: r_, d_, p_. Ser du? Det gamla namnet för ramverket: RDP🤯 (nej, förknippa inte det med Remote Desktop Protocol från Microsoft!! )
Hursomhelst lösningen med prefixet kommer delvis från inspirationen med hur databashanteringslösningar nyttjar prefix av tabellnamn framför sina kolumnnamn för att undvika namnkollisioner mellan kolumner med samma namn fast från andra tabeller. Snabbt, smidigt och elegant helt enkelt!🙌
En annan sak som också "fungerar™" är att om du skulle ha två rutter där båda använder samma test.php-filer för rutten och all data så kommer det inte bli motsägelsefullt beteende för att du raderar ena eller andra rutten.
Det är inte inlagt ännu att säkerhetskopiera raderade hanteringsfiler ännu men det är enkelt att implementera. Så du kan med det enkla kommandot "delete r g/users" radera hela rutten och dess tillhörande hanteringsfunktioner och/eller hanteringsfiler:
PS C:\xampp\htdocs\funkphp\src> php funkcli delete r g/users
[FunkCLI - INFO]: ROUTE: "g/users" parsed as: "/users"
[FunkCLI - SUCCESS]: Deleted Single Route "GET/users" from the Route file!
[FunkCLI - SUCCESS]: Recompiled Trie Route: "funkphp/_internals/compiled/troute_route.php"!
[FunkCLI - SUCCESS]: Deleted Handler File "handlers/r_users.php" and Function "r_users"!
[FunkCLI - SUCCESS]: Deleted Data Handler File "data/d_users.php" and Function "d_users"!
Dold text
Om det finns andra rutter som använder andra hanteringsfunktioner inuti någon utav de där hanteringsfilerna så kommer det meddelas istället i terminalen så att du är medveten om att filerna fortfarande finns kvar men inte allt innehåll i dem.
Med det rapporterat så anser jag att de preliminära bitarna för handlers och middlewares är avhandlade och det är dags att gå vidare till en av de större utmaningarna med ett 99 % funktionsbaserat PHP-ramverk, nämligen det här med databashanterandet...
Kodkampen: ORM-baserad databashantering vs. 99 % funktionsbaserad databashantering
Om du följer One Piece-animen just nu så känner du säkert igen det ovan. Det är "Joy-Wookie-Boy"🤣 som drämmer till Propel ORM med FunkPHP i väntan på de stora bossarna inom ORM-baserad databashantering, det vill säga Drizzle, Prisma och Laravels Eloquent bland annat.
Det är en intressant utmaning som är indelat i två sammanflätade frågor:
1. Hur ska liknande datahydrering kunna åstadkommas på en 100 % funktionell väg?
2. Hur ska utvecklarupplevelsen kunna matcha den ORM-baserade?
Notera att jag sa 100 % funktionellt för datahydreringen, inte datainhämtningen vilket är ett MySQLi-objekt än så länge. Möjligen blir det 100 % funktionsbaserat någon dag™.
Den första punkten är att få till datahydreringen, det vill säga att kunna få tillbaka en önskvärd datapresentation som gör det enkelt att i sidfilerna kunna skriva i stil med:
<h1>Test</h1>
{% foreach d.users as d.user %}
<p>{{d.user.name}}</p>
<p>{{d.user.age}}</p>
<p>{{d.user.and_so_on}}</p>
{% endforeach %}
(ja, anmärk att det är Twigs syntax med {%%} som används. Får se om det blir den eller Blade-syntaxen)
Bokstaven d är den globala $c['d']-variabeln där all data samlas efter validering och/eller hämtning från databas. Sedan kan klassiska extract() nyttjas för att få ut all data på en nivå under $c så vi får $d så att säga.
Självklart kommer vi INTE att använda htmlspecialchars() i stil med:
<?= htmlspecialchars($d['user']['name']);?>
Något sådant vore fullständigt ansvarslöst, eller hur?!😜
Datahydrering på funktionell väg kommer innebära att vi måste representera all data på ett sådant vis att en funktion(!) sedan kan avgöra vilka tabeller som är med (eng. "with") vilka andra tabeller. Eller snarare talat: vilken tabell som ska anses vara en lista av en annan förutsatt att de har ett samband redan.
Exempelvis tabellerna users och posts har tydlig relation: flera poster tillhör en användare. Men när du hämtar data så kan du antingen visa användare med flera poster per användare ELLER poster med den användare som den posten ägs av:
// Användare med en post
{{user.post.id}}
// En post med dess ägande användare
{{post.user.id}}
Du gör exakt samma SQL-fråga i båda fallen men hur du "hydrerar" all data är vad som avgör vilken av de olika ovanstående varianterna som sedan går att skriva i mallfilerna och inte.
Lösningen jag filar på i skallen och sedan i kod med hjälp från Gemini 2.5 Flash (och Pro i den utsträckning det går) är att vid funktionsanropet så anges vilken tabell som är med vilken annan tabell och då har vi "berättat" för funktionen om det ska förberedas för att kunna skriva: {{user.post.id}} eller {{post.user.id}}.
Den andra punkten är något du kanske insåg när du insåg nu att du ska alltså mata in tabellerna och alla kolumnerna du vill använda dig av för att de ska "hydreras" på ett lämpligt vis innan de skrivs in i dina mallfiler.
Så... vem... orkar... skriva kanske dussintals kolumner för några tabeller för att sedan komma ihåg vilket argument som nu var att säga vilken tabell som är med vilken annan tabell? Och hur ska detta lösas med ytterligare nivåer? Det vill säga, varje användare med alla poster med alla kommentarer för varje post för varje användare. Där har vi då en tabell med en tabell som i sin tur är med en ytterligare tabell.
Det blir en spännande utmaning rent funktionsmässigt att tugga igenom på ett effektivt vis. Fast mer spännande är då hur vi ger en utvecklingsupplevelse som känns lika banal som att bara skriva:
<?php // KODEXEMPEL NEDAN ÄR HÄMTAT FRÅN:
// https://www.doctrine-project.org/projects/doctrine-orm/en/sta... 2025-05-04
// list_bugs.php
require_once "bootstrap.php";
$dql = "SELECT b, e, r FROM Bug b JOIN b.engineer e JOIN b.reporter r ORDER BY b.created DESC";
$query = $entityManager->createQuery($dql);
$query->setMaxResults(30);
$bugs = $query->getResult();
foreach ($bugs as $bug) {
echo $bug->getDescription()." - ".$bug->getCreated()->format('d.m.Y')."\n";
echo " Reported by: ".$bug->getReporter()->getName()."\n";
echo " Assigned to: ".$bug->getEngineer()->getName()."\n";
foreach ($bug->getProducts() as $product) {
echo " Platform: ".$product->getName()."\n";
}
echo "\n";
}
Möjligen är ovan inte så mycket bättre men det är objektorienterat och när du skriver $bug i ditt IDE så får du tack vare ditt IDE upp alla tillhörande kolumner i form av metoder att anropa - förutsatt så klart att du har konfigurerat rätt med entiteterna utifrån hur just Doctrine ORM tycks fungera.
Huruvida detta tar mer på PHP-tolken än den lösning jag tänker "kodsnickra" fram återstå att se. Min tanke är helt enkelt gui-vägen där du i princip kryssar i tabeller och deras kolumner du vill välja och sedan genom "smarta" rullgardinsmenyer kan du välja vilka tabeller som ska hydreras med vilka andra tabeller förutsatt att de har en nödvändig relation (dvs., PK & FK). gui-mappen ligger utanför mappen som ska sjösättas på servrar och kollar alltid så det är i localhost eller 127.0.0.1 annars tvärnekar skriptet från att köras.
Sedan när du gjort det så får du färdiggenererad PHP-kod vilket i princip är funktionsanropet med alla argument på rätt plats. På så vis så kommer FunkPHP närmast den underbara biten med objektorienterad programmering i IDE:er där du kan "titta inuti ett objekt för att bara kunna välja de objektmedlemmar som faktiskt finns inuti objektet".
Det är alltså planen för att lösa de där två punkterna så gott som det går!😅
Förhoppningsvis kommer det inte bli allt för klurigt. Allt handlar i början om hur SQL-tabellerna matas in och representeras på ett lämpligt vis inuti den globala $c['data']['tables']-variabeln (även $c['data']['relationships'] kommer att finnas där vilket är den nyckel som bestämmer de möjliga relationerna mellan tabellerna).
Du får önska mig lycka till med de sakerna tills vidare! 😁🫡
(Och vi har ju bara varit inne och smått petat på hela biten med mallmotorn som ska försöka matcha Twig och Blade i både prestanda och tillfredsställande utvecklingsupplevelse!😱😨😬)
Vidareutbildning
Inget nytt att rapportera mer än att igår såg jag "Topp 10 Galnaste x86 Assembler-instruktionerna":
På återseende!
Mvh,
WKF.
P.S. Det finns en lösningsvariant med hanteringsfilerna med hanteringsfunktioner inuti sig vilket är att använda $inner_funk1 = function (){//Abstraction Magic};-variabler inuti varje hanteringsfils primära returfunktion. Däremot upplever jag personligen att det skulle kunna upplevas lite "grötigt" än att tydligt ha function name1(){}, function name2(){} inuti samma fil?🤔Vad anser du?💭D.S.
---------
✔️HT2022-VT2024 TWEUG Webbutvecklings-programmet 120hp (distans)
Senast redigerat
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Webbutvecklingsdagbok - efter studierna
(Felstavningsvarning: För mycket text för att inbyggda rättstavningen i Firefox ska fungera - Volontära Språkpoliser har förvarnats!)
Jobb & Uppdrag
Ingen ny upplaga av arbete från Stockholmskunden idag och inget nytt ännu från än så länge nöjd Uppdragsgivare, eller det lokala IT-företaget nere på stan. En mycket och möjligen snart kritiskt svag start på denna arbetsmånad.
Kombinationen av lågkonjunktur och/eller ens Juniora titel gör det inte hela heller enklare då flera - mer erfarna (Mjukvaru)Utvecklare - på Frilansare Sverige-Slacken rapporterar om hur svårt det är att få tag på Uppdrag just nu trots att konsultbaserade(?) Ework Group pumpar ut nya platsannonser skrikandes dagligen i e-postinkorgen.
Så med det sagt, låt oss ta något mer positivt.
Hobbyprojekt
På grund av bristande jobb än så länge denna vecka så blev det ytterligare nytt fokus på det 99 % funktionsbaserade PHP-ramverket vilket Mycket Snart™ är färdigt för så kallad enanvändarlansering😆!
"//DELIMITERS, BE GONE!!!"
Jag skrev igår om hur förskräckligt det är att se alla dessa //DELIMITERS överallt i filerna. Idag tog jag mig då tiden att reda ut detta en gång för alla: Ska det verkligen behövas en Pratt Parser-liknande implementering för att hitta början och slutet på en hanteringsfunktion inuti en hanteringsfil?🤔
function get_match_function_regex($fnName)
{
if (!is_string_and_not_empty($fnName)) {
cli_err_syntax("[cli_match_function_part] Function name must be a non-empty string!");
}
if (!preg_match("/^[a-z_][a-z0-9_]+$/", $fnName)) {
cli_err_syntax("[cli_match_function_part] \"$fnName\" must use this string syntax: `[a-z_][a-z0-9_]+`!");
}
$regex = '/^function (' . $fnName . ')\(\&\$c\)\s*\/\/ <([A-Z]+)\/([a-z0-9_\-\/]*)>\s*$.*?^};$/ims';
return $regex;
}
function get_match_all_functions_regex($handlerType)
{
if ($handlerType !== "r" && $handlerType !== "d" && $handlerType !== "v") {
cli_err_syntax("[get_match_all_functions_regex] Handler type must be a non-empty string. Choose between: 'r','d', or 'v'");
}
$regex = '/^function (' . $handlerType . '_[a-z0-9_]+)\(\&\$c\)\s*\/\/ <([A-Z]+)\/([a-z0-9_\-\/]*)>\s*$.*?^};$/ims';
return $regex;
}
function get_match_all_functions_regex_without_capture_groups($handlerType)
{
if ($handlerType !== "r" && $handlerType !== "d" && $handlerType !== "v") {
cli_err_syntax("[get_match_all_functions_regex] Handler type must be a non-empty string. Choose between: 'r','d', or 'v'");
}
$regex = '/^function ' . $handlerType . '_[a-z0-9_]+\(\&\$c\)\s*\/\/ <[A-Z]+\/[a-z0-9_\-\/]*>\s*$.*?^};$/ims';
return $regex;
}
function get_match_return_function_regex($fnName, $method, $route)
{
if (!is_string_and_not_empty($fnName)) {
cli_err_syntax("[get_match_return_function_regex] Function name must be a non-empty string!");
}
if (!is_string_and_not_empty($method)) {
cli_err_syntax("[get_match_return_function_regex] Method must be a non-empty string!");
}
if (!is_string_and_not_empty($route)) {
cli_err_syntax("[get_match_return_function_regex] Route must be a non-empty string!");
}
return '/^(return function)\s*\(&\$c, \$handler\s*=\s*.+$.*?^};/ims';
};
function get_match_dx_function_regex()
{
return '/\$DX\s*=\s*\[.*?];$/ims';
};
function get_match_dx_return_regex()
{
return '/return\s*array\(.*?\);$\n/ims';
}
Dear Regex, come forth my Child!
Om du tar en snabbtitt inuti Regex-galenskaperna så finns det en genomgående "hjälte" inom Regex:
$makeMyDayPunkString = '/$.*?^};$/ims';
Först och främst har vi modifikationstecknen "i", "m" och "s" vilket möjliggör att läsa in flera rader i följd oavsett teckenstorlek. När detta sedan kombineras med att vi kräver att något avslutas med i fallet ovan };$ så säger vi att den sista raden som avslutas måste då vara det sista innan radbrytning.
Du kanske ser "\n" i någon Regex vilket är för att skapa ny rad när något ersätts med hjälp av den Regex. En annan sak att anmärka är att de Regex som ska matcha mot en hanteringsfunktion använder ^ för att de är alltid början på en ny rad vilket även gäller den returnerade hanteringsfilens funktion som matchar hanteringsfunktion.
Funktionen som använder sig av flest Regex från ovan är följande "dagens hjältefunktion":
// VERY IMPORTANT WARNING: This function calls a function which uses eval() to parse the validation file!!!
function cli_compile_dx_validation_to_optimized_validation()
{
global $dirs, $exactFiles, $settings, $delimiters, $argv, $dirs;
if (!isset($argv[3]) || !is_string_and_not_empty($argv[3])) {
cli_err("cli_compile_dx_validation_to_optimized_validation() expects a string as input!");
}
$handlerDir = $dirs['validations'] ?? "";
[$handlerFile, $fnName] = get_valid_handlerVar_or_err_out($argv[3], "v");
if (!dir_exists_is_readable_writable($handlerDir)) {
cli_err("Validation Directory \"$handlerDir\" not found or non-readable/writable!");
}
if (!file_exists_is_readable_writable($handlerDir . $handlerFile . ".php")) {
cli_err("Validation Handler file \"$handlerFile.php\" not found in \"funkphp/validations/\" or not readable!");
}
$fnNameRegex = get_match_function_regex($fnName);
$dxVarRegex = get_match_dx_function_regex();
$dxReturnRegex = get_match_dx_return_regex();
$fileContent = file_get_contents($handlerDir . $handlerFile . ".php");
$matchedFn = preg_match($fnNameRegex, $fileContent, $matches);
if (!$matchedFn) {
cli_err("Validation Function \"$fnName\" not found in Validation Handler File \"funkphp/validations/$handlerFile.php\". Check for mispellings or typos?");
}
$matchedEntireFnName = $matches[0] ?? null;
$matchedEntireFnCopy = $matchedEntireFnName;
$matchedDX = preg_match($dxVarRegex, $matchedEntireFnName, $matches2);
if (!$matchedDX) {
cli_err_without_exit("The \"\$DX\" variable not found in Validation Function \"$fnName\" in Validation Handler File \"$handlerFile.php\".");
cli_info_without_exit("Make sure it is intended using CMD+S or CTRL+S to autoformat the Validation Handler File!");
cli_info("It must start as an array: `\$DX = ['<anything_inside_here>'];` or it will not be found!");
}
$matchedSimpleSyntax = $matches2[0] ?? null;
$evalCode = null;
try {
$evalCode = "\nreturn $matchedSimpleSyntax";
$evalCode = eval($evalCode);
} catch (Throwable $e) {
cli_err_without_exit("The \"\$DX\" variable was found but could not be parsed as a valid PHP Array!");
cli_info_without_exit("Make sure it is intended using CMD+S or CTRL+S to autoformat the Validation Handler File!");
cli_info("It must start as an array: `\$DX = ['<anything_inside_here>'];` or it will not be found!");
}
if ($evalCode === null) {
cli_err_without_exit("The \"\$DX\" variable was found but could not be parsed as a valid PHP Array!");
cli_info_without_exit("Make sure it is intended using CMD+S or CTRL+S to autoformat the Validation Handler File!");
cli_info("It must start as an array: `\$DX = ['<anything_inside_here>'];` or it will not be found!");
}
if (is_array($evalCode)) {
cli_info_without_exit("Found \"\$DX\" variable parsed as a valid PHP Array!");
}
$matchedReturn = preg_match($dxReturnRegex, $matchedEntireFnName, $matches3);
if (!$matchedReturn) {
cli_err_without_exit("The \"return array();\" statement not found in Validation Function \"$fnName\" in Validation Handler File \"$handlerFile.php\".");
cli_info_without_exit("Make sure it is intended using CMD+S or CTRL+S to autoformat the Validation Handler File!");
cli_info("The last part of the array() - `);` - must be indented to the same level as the \"return array (\" part!");
}
$matchedReturnStmt = $matches3[0] ?? null;
$optimizedRuleArray = cli_convert_simple_validation_rules_to_optimized_validation($evalCode);
$optimizedRuleArrayAsStringWithReturnStmt = "return " . var_export($optimizedRuleArray, true) . ";\n";
$replaced = str_replace($matchedReturnStmt, $optimizedRuleArrayAsStringWithReturnStmt, $matchedEntireFnName);
$newFileContent = str_replace($matchedEntireFnCopy, $replaced, $fileContent);
$result = file_put_contents($handlerDir . $handlerFile . ".php", $newFileContent);
if ($result === false) {
cli_err("FAILED compiling Validation Rules to Optimized Rules in Validation Function \"$fnName\" in \"$handlerFile.php\". Permissions issue?");
} else {
cli_success_without_exit("SUCCESSFULLY COMPILED Validation Rules to Optimized Rules in Validation Function \"$fnName\" in \"funkphp/validations/$handlerFile.php\".");
cli_info("IMPORTANT: Open it in an IDE and press CMD+S or CTRL+S to autoformat the Validation File again!");
}
}
Kompilera DX-Valideringsregelsyntax till Optimerad Valideringsregelsyntax
Det som händer i funktionen ovan är att vi läser först in en hel PHP-fil som definitivt existerar och går att läsa och skriva till.
Sedan använder vi ett par Regex från ovan för att plocka ut matchande hanteringsfunktion, $DX-variabeln såväl som retur array();-satsen. Vi använder den vanligtvis icke-rekommenderade och den mest farligaste funktionen i hela PHP - eval() - för att snabbt få tillbaka en giltig array() eller null.
Denna skickas i sin tur till en funktion - ej färdig ännu - vilket omvandlar den till en optimerad valideringsregelsyntax. Inuti själva $DX-variabeln som måste vara en array för att matchas skrivs den förenklade valideringsregelsyntaxen. Om konverteringen lyckades så kan nu Regex-matchade retur array();-satsen ersättas med den optimerade valideringsregelsyntaxen.
Till sist så kan vi ta den ersatta och stoppa in igen i en kopia av den matchade hanteringsfunktion vilket i sin tur sedan stoppas in i den redan inlästa $fileContent och sedan skrivs filen över igen. På så vis har vi ersatt på rätt plats och utan några jädrans "//DELIMITERS"!🥰
(Det kan vara som så nu att jag skrev det hela helt fel ovan men det fungerar som det ska i praktiken!)
Det roligaste med den funktionen är att själva flödet för vad som skulle ske och i vilka steg kom helt från mig medan Regex-syntaxförslag och övriga kodsnuttar kom från Gemini 2.5 Preview-gratisversionen.
Möjligen hade den kommit med något annat och kanske mer effektivt men då istället något jag inte riktigt förstått ännu för att vilja använda med gott kodsamvete (*host* Vibe-programmerare *host*).
I princip handlar funktionen om att "simulera" med hur vi kopierar och klistrar in delar av en text inuti en annan för att göra en särskild ersättning. Varför vi egentligen inte bara direkt matchar $DX-variabeln och dess sammanhängande retur array();-sats är för att mönstret upprepas förutom hanteringsfunktionsnamn!
Okej, det går nog med en mer invecklad Regex som först matchar hela hanteringsfunktionen och sedan inuti den matchningen direkt matchar $DX-variabeln och dess retur array();-sats. Möjligen en mycket kort framtida refaktorisering med möjligen färre kodrader men svårare att få snabb överblick över.
På tal om refaktorisering...!🤯
Idag passade jag även på att göra vissa funktioner mer generella. Exempelvis så är hanteringsfilerna och deras hanteringsfunktioner exakt likadana för rutter, data och validering. Om något är väldigt lika, vad bör du göra då? Hm?😜
Mot den bakgrunden skapade jag idag ett par generella funktioner för att skapa och även kunna ta bort antingen enskilda hanteringsfunktioner inuti hanteringsfiler eller även hanteringsfilerna i samma veva om det var sista hanteringsfunktionen i hanteringsfilen.
Exempelvis funktionen function cli_add_a_data_or_a_validation_handler($handlerType) tar antingen bokstaven 'd' eller 'v' för att skapa en hanteringsfil och/eller hanteringsfunktion inuti den valda hanteringsfilen, medan funktionen function delete_handler_file_with_fn_or_just_fn_or_err_out($handlerType, $handlerVar) tar bort en sådan och denna stödjer även 'r'!
Tack vare denna refaktorisering så blev inte bara funktionerna kortare och färre - det hela bidrog till att korta ned med cirka ~500 rader (fast 150+ rader är säkert bara kommentarer!😂) i FunkCLI-filen vilket är den primära filen förrän gui:t är färdigt för en Utvecklare att sitta i och med.
Det här med Output Buffering i PHP...
Egentligen fick jag aldrig lära mig PHP på rätt vis: du skickar först HTTP-huvuden via headers() sedan skickar du all nyttolast (eng. "payload").
Detta även när du bara skriver vanliga HTML-taggar eller via echo, print, printf(), var_dump(), var_export(), vprintf(), debug_print_backtrace(), phpcredits(), phpinfo(), ReflectionExtension::info() eller felmeddelanden beroende på konfiguration med display_errors och/eller error_reporting.
Specialfallet är med var_export() som kan ta true i andra argumentet för att lagra i en variabel vilket du kan se att jag använder i kompileringsfunktionen för valideringsregelsyntaxkonverteringen.
Så jag blev alltid lite förvirrad över varför jag ibland såg text i webbläsaren och ibland inte förrän jag fick mycket kortfattad introduktion till hur PHP på ett "högnivåsätt" fungerar: du skickar HTTP-huvuden först för dessa kan betraktas som "Instruktioner för hur webbläsaren ifråga ska tolka din kommande nyttolast!". Hur ska du tolka något du saknar instruktioner på att tolka först?😵💫
När vi då tar kontroll över utmatningsbufferten i PHP så kan vi göra mycket coola saker som att lagra vissa saker i "den framtida nyttolasten" medan vi skickar iväg diverse HTTP-huvuden såsom kakor och annat gött medan detta inte hade fungerat om vi först råkat ekat ut något och sedan skickat iväg en kaka för då hade vi fått felmeddelanden om att HTTP-huvuden redan skickats.
Varför jag då nämner detta är för att jag har funderat på hur jag ska göra med Mallmotorn när nästlade PHP-filer ska förberedas som "nyttolast" och sedan skickas ut efter alla HTTP-huvuden. Nästlade PHP-filer är alltså att du har en fil som vill inkludera en annan fil som i sin tur kanske också vill inkludera en annan fil.
Och vad händer när include_once eller kanske mer rekommenderade require_once körs? Jo, PHP-filens innehåll läses in som om den redan fanns där så om du inte har koll på din utmatningsbufferts status (påslagen eller avslagen?) så riskerar du att skicka iväg "nyttolast" istället för att bara göra något med den först.
Fast varför ens använda den när det finns en risk att dess högsta tillåtna buffertstorlek inte går att ställa in hos ett webbhotell där webbplatsen sjösätts?
Istället kan vi nyttja kraften av file_get_contents() och använda oss av preg_replace_callback() för att iterativt läsa in ytterligare i varje huvudsakliga fil med hjälp av en återanropsfunktion som då kan ersätta den nuvarande inlästa filen.
Föreställ dig då {%part(headers/test)%} vilket då kommer tolkas som att läsa in test.php-filen i mappen headers vilket i sin tur ligger i en rotmapp som alltid part() utgår ifrån.
När test.php-filens innehåll har lästs in och ersatt {%part(headers/test)%} så tittar vi igen i samma inlästa text: Finns det någon ny {%part(mapp/fil)%} att läsa in?
Om det finns så upprepar vi annars så är vi färdiga med att läsa in alla nästlade tillhörande PHP-filer för den där filen att senare kompilera till en vanlig PHP-fil som sedan ekas ut till webbläsaren. På så vis slipper vi hålla på med potentiellt buffertstorleksbegränsad utmatningsbuffert!🫡
"Det är planen tills att verkligheten har slagit till en på käften!"
- ett omskrivet citat med upphovsperson Mike Tyson
Vidareutbildning
Inget nytt att rapportera mer än att jag såg följande YT-klipp idag om att "React kanske håller på att implodera":
Det anmärkningsvärda var inte klippet i sig utan en kommentar om att "PHP håller på att göra en comeback!" vilket jag så klart är lite partisk kring!😬
På återseende!
Mvh,
WKF.
---------
✔️HT2022-VT2024 TWEUG Webbutvecklings-programmet 120hp (distans)
Senast redigerat
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Webbutvecklingsdagbok - efter studierna
Jag har både mycket dåliga nyheter och mycket goda nyheter ! 🫡
Jobb & Uppdrag
Stockholmskunden meddelade för någon vecka sedan att det pågår kontorsflytt och att deras nuvarande verksamhet har pausats vilket betyder att jag har varit definitionsmässigt talat varit arbets- och/eller uppdragslös. Under den tiden har jag då fokuserat på hobbyprojektet.
Idag pratade jag med den än så länge fortfarande mycket nöjda Uppdragsgivaren om min situation. Personen sa att denne skulle dra i sina trådar av kontakter och se om jag kunde få någon kontaktuppgift där jag skulle kunna presentera mig. Jag har rådfrågat i lämpliga Discord-grupper om hur detta bör gå till.
Utmaningen är att jag inte vet vad jag kan hjälpa med förrän jag vet delvis om domänet, fått titta delvis på icke-sekretessbelagd kodbas, och även veta konkreta saker som utvecklingsstack, deadlines, etc. Annan utmaning är sedan också tidigare sagt att Uppdragsgivaren ej är tillräckligt tekniskt insatt för att kunna gå i gott ord om mig och det får absolut inte uppstå något missförstånd om att jag skulle vara duktigare än jag faktiskt är.
Möjligen dyker det upp något under veckans gång eller så blir det en "ekonomiskt tunn" sommar så att säga!
Hobbyprojekt
Om Du öppnar upp min öppna källkod för mitt hobbyprojekt - vilket du bör veta exakt vad det är om du är en regelbunden läsare - så råder jag dig att kika i filen "_internals/functions/d_data_funs.php" och börja på rad 70 där du ser funktionen som handlar om att först hämta en valideringsfil eller bara returnera null samt lagra felmeddelande i lämplig undernyckel i $c['err'].
Om du tittar i koden nedan här i inlägget :
<?php
// Data Handler File - Created in FunkCLI on 2025-05-24 08:52:25!
// IMPORTANT: CMD+S or CTRL+S to autoformat each time function is added!
function d_test(&$c) // <POST/test/:id>
{
// Created in FunkCLI on 2025-05-24 08:52:25! Keep "};" on its
// own new line without indentation no comment right after it!
$v_file = funk_use_validation_get_validation_array_or_err_out($c, "v_test");
$validatePOST = funk_use_validation($c, $v_file, "JSON");
$test = [
'v' => $c['v'],
'v_ok' => $c['v_ok'],
'v_config' => $c['v_config'],
'v_data' => $c['v_data'],
];
dj($test);
};
return function (&$c, $handler = "d_test") {
return $handler($c);
};
Exempel på datahanteringsfil
Så ser du hur den först då hämtar följande valideringsfil:
<?php
// Validation Handler File - Created in FunkCLI on 2025-05-24 08:52:30!
// Write your Validation Rules in the
// $DX variable and then run the command
// `php funkcli compile v v_test=>$function_name`
// to get the optimized version below it!
// IMPORTANT: CMD+S or CTRL+S to autoformat each time function is added!
function v_test(&$c) // <POST/test/:id>
{
// Created in FunkCLI on 2025-05-24 08:52:30! Keep "};" on its
// own new line without indentation no comment right after it!
// Run the command `php funkcli compile v v_test=>v_test`
// to get optimized version in return statement below it!
$DX = [
'name' => 'string|required|between:2,30',
'age' => 'integer|required|between:18,30',
];
return array(
'name' =>
array(
'<RULES>' =>
array(
'required' =>
array(
'value' => NULL,
'err_msg' => NULL,
),
'string' =>
array(
'value' => NULL,
'err_msg' => NULL,
),
'between' =>
array(
'value' =>
array(
0 => 2,
1 => 30,
),
'err_msg' => NULL,
),
),
),
'age' =>
array(
'<RULES>' =>
array(
'required' =>
array(
'value' => NULL,
'err_msg' => NULL,
),
'integer' =>
array(
'value' => NULL,
'err_msg' => NULL,
),
'between' =>
array(
'value' =>
array(
0 => 18,
1 => 30,
),
'err_msg' => NULL,
),
),
),
);
};
return function (&$c, $handler = "v_test") {
return $handler($c);
};
Exempel på kompilerad valideringsfil
Den i sin tur består av en $DX-variabel vars namn antyder om Utvecklarupplevelsen. Du skriver sedan php funkcli compile v v_test=>v_test i terminalen så länge du har PHP version 8.2 lägst installerat. Denna skapar då return array() vilket är det som laddas in i $v_file (eller null vid misslyckande) i d_test.php-filen.
Sedan börjar det nästintill otroliga (tycker jag):
Först körs funk_use_validation (se kodrad 714 i källkoden) vilket tar parametrarna $c-globala variabeln, den optimerade valideringssyntaxregelarrayen, källan för data att validera (t.ex. $_GET, $_POST eller JSON än så länge, $_FILES kommer senare!) samt valfri boolean-värde. Det sistnämnda är huruvida antingen all data måste valideras för att det ska lagras i $c['v_data']-variabeln eller om delvis validera data får lagras. Jag frågade Gemini 2.5 Thinking och tipset var att tänka på inkompletta formulär där du då kan återge validerad data igen medan övriga fält rensas och varningar visas.
Funktionen anropar nu min mest komplicerade funktion hittills (av egen åsikt) vilket är funk_validation_recursively_improved (kodrad 412 i källkoden) vars namn antyder att den är både rekursiv och förhoppningsvis förbättrad. När vi pratar om rekursiva funktioner så har vi den klassiska frågan, "Vad är basfallet som ska avbryta rekursionen och därmed de stackade anropen? Svaret i detta fall är: funk_validation_validate_rules (kodrad 129 i källkoden).
Varje anrop till funk_validation_validate_rules innebär att ett korrekt enskilt typ av data valideras nu. Det kan vara strängar, associativa/numrerade arrayer, olika slags nummer, booleaner, och bland strängar finns det även särskilda typer såsom password och email bland annat. Dessa kommer då med egna valideringsregler inbyggda direkt i deras datatyper. När enskilt data har validerats korrekt så kommer den inte ha några felmeddelanden förknippade med några regler eller så får den det på regelnivå. Rekursionen sker främst i data med data under sig såsom associativa och/eller numrerade arrayer. Sistnämnda har även specialfallet när själva roten av alla data är en numrerad array.
På tal om datatyper så var det viktigt att skapa en konsekvent utvecklingsupplevelse för den enda troliga slutanvändaren (Jag! 😂) så för varje valt givet datafält så kan det ha en datatyp. En sak som tog väldigt lång tid var alla kontroller och varningar och i många fall stoppandes felmeddelanden vilket äger rum vid kompileringen av den förenklade valideringssyntaxen vilket betyder att Utvecklaren måste korrigera något.
Då jag inte har några problem att skriva mycket så finns det gått om gula varningar, röda felmeddelanden såväl som många blåa uppmuntrades informationstexter om hur det hela ska användas.
En annan viktig sak var att göra det enkelt: skriver du datatypen string och sedan min, max eller kanske between så ska den bara "fatta" att det nu är mångbytes-mässiga längden på en sträng medan för heltalsdatatypen integer så är det värdestorleken istället. Och ja, antalet element i arrayer gäller också.
Bilden nedanför visar exempel på när JSON-data skickas och först visas var_dumpad data som skickats och sedan returvärdet av valideringen ('v').
Lägg märke till i detta fall så är v_data null på grund av att funktionen anropades med true i booleanen (standardvärde när det lämnats tomt vid funktionsanrop) för huruvida all data måste validera annars "hydreras" ingen validerad data?
Du ser också "v_config" vilket är en intressant lösning att kunna nyttja tack vare den globala $c-variabeln. Den innehåller valfria specialegenskaper vid valideringen. Exempelvis kanske varje enskild regel som tillhör samma data som valideras få extraregeln "stop" vilket då avslutar all resterande validering för det datumet (data singular).
En annan specialregel är "field" för om du tittar i bilden så ser du "age" vilket ser illa ut i standardmeddelandet. Vad du anger efter "field" och dess kolon är vad du vill att fältet ska visa i standardfelmeddelandet.
Kodsnutten nedan visar också hur du får in dina egna felmeddelanden vilket måste ske inuti dubbla citattecken och parenteser. Själva hela $DX-variabeln bearbetas med reguljära uttryck vilket kräver att arrayen börjar med enkelfnuttar även om du skulle kunna köra med dubbelfnuttar.
$DX = [
'name' => 'string("Det måste vara en sträng!")|required|between:2,30',
'age' => 'integer("Heltal, tack!")|required|between:18,30("Age between 18 and 30 please!")|field:Age',
];
Observera att när du skriver eget felmeddelande så följer inte fältet med (t.ex. Age) för den regeln utan det är vad du får i alla standardfelmeddelanden när du inte angett något eget sådant för en given regel i en given inmatningsdatum (data singular)).
En rolig tvist på det hela var när jag hade fått till numrerade arrayer vilket du anger med hjälp av "*" som exempelvis:
$DX = [
'user.*' => 'list("Varje användare måste vara en numrerad array!")|required|between:2,30',
'user.*.age' => 'integer("Heltal, tack!")|required|between:18,30("Age between 18 and 30 please!")|field:Age',
];
Snabb frågesport fråga nu: Vad innebär between:2,30 för datatypen array?🤔Precis! Nu agerar den som antalet element du behöver - färst 2 och flest 30. Färre än 2 eller fler än 30 utvärderat av den inbyggda array count-funktionen i PHP så blir det felmeddelande.
Har du förresten kommit på vad det var för tvist jag stötte på med numrerade arrayer? Det finns ju ett specialfall med numrerade arrayer. Det vill säga: vad händer när hela roten är en enda kanske stor och lång numrerad array? Alltså:
$DX = [
'*' => 'list("Varje användare måste vara en numrerad array!")|required|between:2,30',
'*.age' => 'integer("Heltal, tack!")|required|between:18,30("Age between 18 and 30 please!")|field:Age',
];
Konstruktionen för funk_validation_recursively_improved var först ej hanterad för detta för den utgick ifrån att det alltid var ett förutbestämt datafält på vänstra sidan och högra sidan innehöll då reglerna (se den blossande kodraden 420 i källkoden) vilket satt sig på sin vassa kant så fort det är en numrerad array på vänstra sidan.
I princip blev lösningen att hantera specialfallet vilket då innebar att funktionen har två stora if-satser varav första är störst som du väl ser. När det väl lyckades så kände jag verkligen så här!
Hm, vad händer då om det är?:
$DX = [
'*.*' => 'list("FML!")|required|between:2,30',
'*.*.age' => 'integer|required|between:18,30|field:Age',
];
I nuvarande implementering så stöds detta ej. Det stoppande rött felmeddelande vid kompilering av den förenklade valideringssyntaxen så det kommer ej att gå. Och skulle Utvecklaren manuellt ändra i return array()-delen och sedan klaga så får de skylla sig själva.
Jag fick det delvisa tänket från ett YT-klipp om varför vissa saker stannar upp i TV- & datorspel för att datorer är värdelösa på att hantera oändlighet (åtminstone teoretiskt talat). Vad du gör i spel är att något som ska animeras hela tiden kanske har en tid som nollställs efter en viss loop och sedan börjar om igen.
Spel som saknar detta kan få skumma effekter då om du befinner dig på samma plats i flera timmar eller dagar som i fallet med Super Mario 64 (tror det är sju dagar du ska stirra på den animerade tavlan för vattenbanan innan du kan spöa Bowser en andra gång).
Med andra ord så kan du låta spelet stå på i sju dagar så kommer tavlan att sluta animeras för att dess inbyggda tidigare ej nollställs utan flyttalet överflödas. Frågan är då: Är detta rimlig normalanvändning av spelet så att Nintendos programmerare borde stå till svars? Personligen anser jag nej.
Liknande resonemang för jag då i den bistra sanningen och faktumet att trots alla kompileringsgenererade koddelar så kan Du ju ändå ändra i koden som ej fångas upp under körning för allt kan inte fångas upp utan att skapa onödig så kallad "overhead".
Sedan är det upp till var och en att tycka till hur mycket mjukvara ska rädda slutanvändarna från sig själva och i vilken utsträckning de ska ta vuxet ansvar för sin egen existens och därmed dagliga handlingar.
Hursomhelst, om vi skippar den skumma tangenten från ingenstans så är jag personligen rätt stolt över hur det fungerar i dagsläget. Funktionen som kompilerar förenklade valideringssyntaxregler till förhoppningsvis optimerade valideringsregler finns i cli_funs.php på kodraderna 992 till och med 2588!
Och majoriteten av koden är i princip bara att kontrollera så att "det är svårare att råka göra fel samtidigt som det är lättare att göra rätt!" vilket är en livsfilosofi jag bär med mig sedan något decennium tillbaka.
Möjligen går det att bryta ut denna valideringsbit till en egen simpel modul och därmed repo för skarp lansering trots att det redan finns en uppsjö av PHP-baserade valideringsbibliotek.
Ja, just det: Den har två nuvarande svagheter mycket värda att nämna:
1. Den klarar som sagt var ej flerdimensionella numrerade arrayer såsom [0][0], [0][0][0], och så vidare. Möjligen går det att få till med viss ytterligare kontroll i rekursionsbeteendet men istället föredrar jag att bara tillhandahålla de separata valideringsreglerna åt Utvecklaren som får så lov att skriva egna nästlade loopar!
2. Till skillnad från Laravel (vars valideringsregel jag tagit inspiration från och även kommit på andra som inte finns med där!) så finns inga supersmarta valideringsregler som kan agera utifrån vad andra datafält har validerats som. Möjligen går detta att få till genom att lagra diverse "valideringstillstånd" i $c['v_config']-variabeln.
Samtidigt gällande punkt två ovan så tänker jag att det kan finnas en risk för "förvirring" eftersom du då måste förstå vad specialregeln gör. Den som suttit med valideringsbiblioteket i dussintals timmar så är det ju så klart uppenbart likt någon som suttit med en bana i Super Mario Maker 2 medan den som kastas in i det hela inte alls kanske ser det "som är så uppenbart om du bara hade lagt lika många timmar på det som jag!"
Det finns däremot en datatyp som vill nyttja faktumet att det finns andra datafält som den vill samspela med och det är strängdatatypen password_confirm:regular_password. Alltså, du skriver password_confirm som datatyp och sedan måste du ange vilket annat datafält som den ska jämföra mot vilket i sin tur måste vara strängdatatypen password.
En viktig sak att fixa här också är att strängdatatypen password måste valideras före detta sker annars kommer det bli som om lösenordet aldrig angavs och därmed kan det hela valideras felaktigt. (återigen intressant ytterligare exempel på alla små "gotchas!" när en försöker skapa komplext sammanhängande system som hjälper Utvecklaren samtidigt som den kan göra sin magi med så lågt Ordo-värde som möjligt!)
Vidareutbildning
Inget nytt att rapportera mer än att jag har väl förhoppningsvis blivit lite på bättre att skriva rekursiva funktioner? Det gäller att hålla koll på vad som förs vidare i den nästlade rekursiva stacken och här är variabler som skickas som referenser underbara att använda då ett rekursivt anrop kan innehålla en djupare nyckelnivå medan den behåller samma nivå en rekursion uppåt.
Exempelvis fick jag katastrofala kodförslag från Gemini 2.0 Thinking som tyckte att sättet att hålla koll på nyckeldjupet i $c['v']-variabeln där alla valideringsfelmeddelanden lagras var att först array-merge för nuvarande djup och sedan köra foreach för att bygga ihop nuvarande nyckeldjup till $c['v']-variabeln.
Det skulle betyda att varje array_merge och foreach skulle bli längre för varje nyckeldjup! Och denna/dessa LLM:er ska ersätta Utvecklare Snart™? Fast det är ju inte Utvecklarna som ersätts av LLM:er utan det är personer som kan sparka Utvecklarna som ersätter dem med "AI" i hopp om att det är/blir ekonomiskt värt det i slutändan.
Nä, nu måste jag gå och varva ned mig lite!
På återseende!
Mvh,
WKF.
---------
✔️HT2022-VT2024 TWEUG Webbutvecklings-programmet 120hp (distans)
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Webbutvecklingsdagbok - efter studierna
Jobb & Uppdrag
Inget nytt att rapportera mer än att jag gick in på en Facebook-grupp och besvarade vad som såg ut att vara en uppdragsannons efter tips från en god Discord-vän. Inget svar ännu dock.
Hobbyprojekt
Några anmärkningsvärda förändringar
I det ambitiösa hobbyprojektet har jag nu tagit fram en uppdaterad version av de så kallade Valideringshanteringsfilerna och deras innehållande Valideringsfunktioner:
<?php
namespace FunkPHP\Validations\v_test;
// Validation Handler File - Created in FunkCLI on 2025-05-29 21:02:46!
// Write your Validation Rules in the
// $DX variable and then run the command
// `php funkcli compile v v_test=>$function_name`
// to get the optimized version below it!
// IMPORTANT: CMD+S or CTRL+S to autoformat each time function is added!
function v_test2(&$c) // <>
{
// Created in FunkCLI on 2025-05-29 21:02:46! Keep "};" on its
// own new line without indentation no comment right after it!
// Run the command `php funkcli compile v v_test=>v_test3`
// to get optimized version in return statement below it!
$DX = [
'one_digit' => "required|digit",
'user_password' => "required|password|between:5,10",
'user_password_confirm' => "required|password_confirm:user_password",
];
return array(
'<CONFIG>' =>
array(
'passwords_to_match' =>
array(
'user_password' => 'user_password_confirm',
),
),
'one_digit' =>
array(
'<RULES>' =>
array(
'required' =>
array(
'value' => NULL,
'err_msg' => NULL,
),
'digit' =>
array(
'value' => NULL,
'err_msg' => NULL,
),
),
),
'user_password' =>
array(
'<RULES>' =>
array(
'required' =>
array(
'value' => NULL,
'err_msg' => NULL,
),
'password' =>
array(
'value' => NULL,
'err_msg' => NULL,
),
'between' =>
array(
'value' =>
array(
0 => 5,
1 => 10,
),
'err_msg' => NULL,
),
),
),
'user_password_confirm' =>
array(
'<RULES>' =>
array(
'required' =>
array(
'value' => NULL,
'err_msg' => NULL,
),
'password_confirm' =>
array(
'value' => 'user_password',
'err_msg' => NULL,
),
),
),
);
};
return function (&$c, $handler = "v_test3") {
$base = is_string($handler) ? $handler : "";
$full = __NAMESPACE__ . '\\' . $base;
if (function_exists($full)) {
return $full($c);
} else {
$c['err']['FAILED_TO_RUN_VALIDATION_FUNCTION-' . 'v_test'] = 'Validation function `' . $full . '` not found in namespace `' . __NAMESPACE__ . '`!';
return null;
}
};
Nya versionen av Valideringshanteringsfiler med Valideringsfunktioner
Nu framgår det först en så kallad namespace vilket fyller två syften i detta sammanhang:
Kapsla in funktionerna på filnivå så nu går det att ha en fil som innehåller samma Valideringsfunktion "v_test2" utan att den skulle krocka med en annan Valideringshanteringsfil som kanske laddas in vid en och samma HTTPS-förfrågan som behandlas och besvaras.
Kalla mig "bakom kodflötet" men jag har tidigare inte förstått existensen med så kallade namespaces inom programmering. I PHP så verkar den fylla det extra syftet att kunna förenkla användningen av funktioner. Exempelvis med hjälp av "use"-nyckelordet kan du då syfta på en funktion med särskilt namn från en särskild fil utan att behöva skriva in hela filnamnet och dess funktion. Det andra syftet jag tänker för det är att tydligare visa vad för slags fil du är inuti även om "r|d|v|s_"-prefixet hjälper till. "s_"-prefixet står för SQL-hanteringsfiler med SQL-hanteringsfunktioner så att säga!
Detta ställer den viktiga frågan: "Bör prefixen_ vara kvar eller ej i respektive filer?" eller kommer de att upplevas som överflödiga? 🤔Lägg även märke till denna lilla men signifikanta förändring:
function v_test2(&$c) // <>
Vad är grejen med "<>"?
Anmärk "<>"-tecknen vilket nu är tomma och annars innehåller HTTPS-metoden/exakt_rutt_med_valfria_parametrar. I sammanhanget för Validerings- och SQL-hanteringsfiler inklusive deras -hanteringsfunktioner så kommer de fylla syftet att valfritt på eget måfå av Utvecklaren innehålla vilka tabeller de syftar på.
Exempelvis:
function v_test2(&$c) // <authors,books*2>
Betyder att du har Validering inuti v_test2-hanteringsfunktionen för de inlagda tabellerna authors och books varav sistnämnda innebär en numrerad lista med två element för den tabellen i och med "*2"-syntaxen.
När denna Valideringshanteringsfunktion då skapas med dessa valda tabeller så kontrolleras de så klart först att de finns inuti tabellarrayen, annars nekas Utvecklaren och ombes att antingen ange rätt tabeller eller inte ange några tabeller vid skapandet av Valideringshanteringsfunktionen.
Varför det blev så här var för att jag insåg att det hela med Validering såväl som SQL-frågor bör ej endast vara förknippade med bara en enstaka HTTPS-metod och dess exakta rutt med möjlig dynamisk parameter utan bör kunna återanvändas!
Och så fick jag en "uppenbarelse" om vad <> då kunde användas till inuti de två annorlunda hanteringsfilerna om de inte direkt kunde kopplas till särskilda HTTPS-metoder med någon rutt: vilka tabeller de syftar eftersom filerna handlar om just databastabellerna inlagda via SQL-filer från den nyligen tillagda schemas-mappen.
ScaffoldingPHP eller vadå?😂
En sak jag börjat inse med CLI-filosofin i detta hobbyprojekt är att vad du i princip gör är att "scaffolda" fram saker såsom HTTPS-specifika rutter, förknippade hanteringsfiler och hanteringsfunktioner för dessa.
Samtidigt har du de mindre icke-specifika hanteringsfilerna och hanteringsfunktionerna gällande Validering och SQL-frågor där det snarare är valfritt huruvida du vill syfta på en eller flera särskilda databastabeller eller inte.
Så kallad "flexibel valfrihet" är mycket viktigt anser jag för Utvecklare så att de kan välja själva hur de vill använda någonting. Nackdelen med för mycket valfrihet samtidigt är att du kanske blir "paralyserande av allt analyserande" likt när du har för mycket att välja bland hos streamingtjänsterna.
En annan sak är något jag kallar för "Super Mario Maker 2/SMB2-metaforen". Föreställ att du skapar en bana i SMB2 vilket tagit dig tiotals timmar där du då inte bara har tänkt igenom hur den är tänkt att spelas utan också fört egna resonemang bakom dessa.
Men det är också grejen: Du har fört egna resonemang om hur din bana är tänkt att spelas utan att kanske möjligtvis kommunicerat det på ett lika uppenbart sätt medan allt är så uppenbart för dig för du har ju varit med från början med dina egna resonemang vid framtagningen såväl som tiden du har lagt på det hela.
Tänk dig sedan att du kastar in en spelare som har 0 sekunders erfarenhet av din bana. Kommer de att förstå varför den ser ut som den gör? Varför den tycks vara designad som den är? och så vidare. Liknande går att säga om alla dessa så kallade "utvecklingsramverk" - med en signifikant skillnad dock jämfört med metaforen ovan.
Till skillnad från SMB2-byggskapandet så kan du tillhandahålla "spelmanualer" eller "dokumentation" som det så fint heter inom utvecklingsvärlden. På så vis kan du vägleda nya spelare (eller Utvecklare i detta fall) att ta sig an din bana/ditt ramverk.
Men! Likt "spelmanualer" så kan det hela kännas dålig design från grunden om du ska behöva läsa en slags "manual" för att kunna spela ett spel eller kunna använda ett ramverk genom att först behöva läsa dess "dokumentation"?🤔
Tänk om banan i sig eller ramverket i sig kunde kommunicera vad du ska göra beroende på var du är någonstans? Exempelvis i bra spel så kan du visas i en säker miljö vad du förväntas göra och inte göra. En annan form av "dokumentation" är således kommentarer inuti de scaffoldade filerna inklusive exempelanvändning som följd av scaffoldandet[/i].
Genom finurlig placering och design av dem så går de även lättsamt att bara sudda ut eller ignorera och samtidigt få en slags förståelse för hur respektive fil är tänkt att användas genom att de alltid fylls med pseudodata.
En halvträff🎯 mot "ORM-konkurrenterna"?
Den skämtsamma frågan är så klart hur jag med detta hobbyprojekt ska besegra "ORM-jättarna" inom SQL-frågeskapandet. Det är ju så oerhört angeläget att bara skriva sitt så kallade "schema" och "relationerna" mellan dem och sedan bara använda alla de inbyggda om än nästintill "magiska" metoderna för att plocka ut data.
Och ja, du slipper ju även bry dig om hur denna data ska "paketeras" (eng. "data hydration") utan du anger bara vilka tabeller som ska vara "barn" (eng. "with") åt andra och så är det färdigt. All data hämtas och paketeras enligt dina önskemål - med bara ett antal kedjemetodanrop till ditt instansierade ORM-objekt!🤯
Om vi tittar tillbaka på Valideringsfunktionen fast vi byter ut den mot en så kallad SQL-frågefunktion så kan vi se ledtråden inuti "<>"-tecknen:
function s_test(&$c) // <authors,books>
I kodexemplet ovan så ser vi tabellerna authors och books vilket kan kontrolleras då om de först och främst existerar, och sedan om de har någon relation (sammankopplade primär- & sekundärnycklar) och därmed om de kan "hydreras" på något vis.
I och med det så kan de viktiga nyckelorden för en klassisk SQL-SELECT-fråga såsom FROM, (INNER/OUTER/LEFT/RIGHT) JOIN, ON WHERE, GROUP BY, HAVING, ORDER BY ASC/DESC, och avslutningsvis LIMIT OFFSET COUNT hanteras korrekt genom att det är känt vilka tabeller som kan slås samman beroende på val av JOIN så klart och det är inte krav på att nyttja ON utan bara om det önskas - återigen: valfrihet!
Gällande valfriheten igen så är infrastrukturen att förutom att du måste ange dina rutter för dina olika valda HTTPS-metoder och varje sådan måste ha minst en tilldelad hanteringsfunktion som finns inuti någon vald hanteringsfil så är det sedan helt och hållet upp till Utvecklaren hur de vill ta sig an det hela därpå.
Hypotetiskt talat så kan du i princip sköta allt inuti en och samma hanteringsfunktion inuti en given hanteringsfil:
Validera eventuella "ruttparametrar".
Validera eventuella erhållna data från användaren.
Eventuellt hämta data baserat på det från vald databas.
Antingen "hydrera" erhållen databasdata eller inte göra det.
Sätta meta-data för den sida du vill returnera.
Sätta layoutfiler den sida du vill returnera ska använda sig av.
Sätta diverse HTTPS-huvuden i samband med den returnerade sida du vill skicka tillbaka.
Skicka tillbaka antingen JSON och/eller din renderade "mallmotoriserade" sida.
Gör något ytterligare efter du skickat tillbaka svar: logga, cacha, och/eller annat!
Men vill du dela upp det mer så kan du skapa en Datahanteringsfil med en Datahanteringsfunktion vilket du endast använder för att separera på vad som är kopplat till eventuell data (för du kanske bara returnerar en icke-dynamisk sida utan något innehåll som först måste hämtas från en databas).
💩"I slutändan är det ingenting mer än en enda stor fet "kodbajskorv!"💩
Nu har jag frossat alldeles för mycket på mina egna "paradpruppar" så är det dags att komma ned på Jorden igen!😂
Visst är det lite smågulligt att "Lilla Junioren" har tagit fram ett så kallat "relativt valfritt ramverk" i det så kallade "låstasspråket PHP" vilket du använder när du inte vill kunna använda asynkron kodkörning på internationell invå med lastbalansering, delade data (eng. "sharding").
Jag pratar ned så där - nästan i en slags "reflexmässig Jantelagsanda" - för att visa att inte ännu har jag blivit så där "kodmässigt fåfäng" och tro att jag är någon slags "Thought Leader On Web Development" bara för att jag snickrat ihop något smått komplicerat "K1dd13 Zcr1pT" på lite drygt två månader snart.
Hobbyprojektet är både delvis imponerande och samtidigt inte eftersom jag inte har någon annan Slutanvändare än jag själv. Lite åt det hållet var en välmenande konstruktiv kommentar jag fick av någon på Discord angående det hela.
Dessutom återupprepar jag det nästan alla Utvecklare egentligen stör sig på: "Alla vill skapa ett ramverk för att lösa något andra ramverk inte hade löst men istället skapar de bara nya problem som då andra vill skapa ramverk för att lösa och så fortsätter det hela!".
Jag ska erkänna: Visst har jag till och från haft dessa klassiska irrationella dagdrömmar om att: "Tänk om folk på reddit börjar använda detta och massa populära CodeTubers börjar prata om det för att det är så sinnessjukt - funktionsbaserat ramverk i PHP - WTF, liksom?!" Även jag har bara en lättpåverkad aphjärna jag med!
Hursomhelst så har jag lärt mig en del om diverse datastrukturer och deras algoritmiska implementationer, viss infrastrukturdesigntänk inom PHP och en del strängmanipulering, eller ja, en hel del strängmanipulering!😅
(Jag misstänker samtidigt att potentiella Arbets- och/eller Uppdragsgivare skulle resonera något i stil med om de fått reda på detta slags hobbyprojekt: "Så personen har ägnat flera månader på ett eget ramverk - som i princip ingen kommer att få reda på ännu, mindre vilja prova - istället för att bemästra nuvarande vedertagna teknikstackar? Saknar personen känsla för prioriteringar här i arbetslivet?")
TLDR; Jag pratar både gott och skit om det så kallade hobbyprojektet för att visa att jag inte blivit fåfäng samtidigt jag är stolt över det lilla jag åstadkommit på den tid som gått!🫡
Vidareutbildning
Inget nytt att rapportera förutom att jag såg detta mycket intressanta simpla YT-klipp om hur "Tre Olika Sätt JS-Ramverk Renderar DOM i Webbläsarna":
Om jag förstått rätt och det stämmer så är snubben skaparen bakom SolidJS så inte helt bakom kodflötet bör personen då vara.
Personligen tycker jag det är lite lustigt att Virtual DOM med differentiationsanalys var det första stora heta innan det blev insikten att: "Ja just det, detta innebär ju att det växer proportionellt med antalet nästlade DOM-element. Vi kanske skulle bara 'lyssna' på vilka elements vars innehåll faktiskt ändras?"
Lätt att vara efterklok så klart. Om jag förstått det hela korrekt så kom ReactJS till främst för att lösa problem internt hos Facebook innan det sedan blev "FOSS"(?) och resten är historia?🤔
När det gäller Signal-paradigmet så undrar jag samtidigt hur det hela skalar om varje sak som ska få en "signal" blir då ett element att hålla reda på och så ska det kanske sammankopplas med andra vilket då betyder att de måste vara varandras så kallade "observatörer"?🙃
På återseende!
Mvh,
WKF.
---------
✔️HT2022-VT2024 TWEUG Webbutvecklings-programmet 120hp (distans)
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Visa signatur
MSI PRO Z790-P WIFI | Intel i9 13900K | 128 GB DDR5
GTX 4070 12 GB
Samsung 990 Pro 4 TB | WD Black SN850X 2 TB Gen 4 | 2 x 1 TB Samsung 970 EVO Plus
3 x ASUS 27" | 1 x Philips 49"
Senast redigerat
