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"
Webbutvecklingsdagbok - efter studierna
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
I väntan på NSW2!🥲
Jobb & Uppdrag
Inget nytt att rapportera.
Hobbyprojekt
Mer abstraktion åt kodfolket!!!
Äntligen lite bättre abstraktion gällande Valideringshanteringsfiler och deras Valideringshanteringsfunktioner vilket då även går att extrapolera till de kommande SQL-filernas och deras motsvarande SQL-funktioner:
function funk_use_validation(&$c, $validationHandler, $validationFunction, $source)
{
if (!is_string($validationHandler) || !is_string($validationFunction)) {
$c['err']['FAILED_TO_RUN_VALIDATION_FUNCTION-funk_use_validation'] = "Validation Function needs a valid string for `\$validationHandler` and `\$validationFunction`!";
return false;
}
$optimizedValidationArray = null;
if (isset($c['v_handlers'][$validationHandler])) {
$optimizedValidationArray = $c['v_handlers'][$validationHandler]($c, $validationFunction) ?? null;
}
else {
$validationFile = dirname(dirname(__DIR__)) . '/validations/' . $validationHandler . '.php';
if (file_exists_is_readable_writable($validationFile)) {
$validationDataFromFile = include_once $validationFile;
if (is_callable($validationDataFromFile)) {
$c['v_handlers'][$validationHandler] = $validationDataFromFile;
$optimizedValidationArray = $c['v_handlers'][$validationHandler]($c, $validationFunction) ?? null;
} else {
$c['err']['FAILED_TO_LOAD_VALIDATION_FILE-funk_use_validation'] = 'Validation Handler File ``' . $validationHandler . '.php` did not return a callable function.';
return false;
}
} else {
$c['err']['FAILED_TO_LOAD_VALIDATION_FILE-funk_use_validation'] = 'Validation Handler File `' . $validationHandler . '.php` not found or not readable! (Reminder: a single string is parsed as `v_file=>v_function`!)';
return false;
}
}
if ($source === "FILES") {
$c['err']['FAILED_TO_RUN_VALIDATION_FUNCTION'] = "Use Validation Function `funk_use_validation_files(&\$c, \$optimizedValidationArray)` instead to validate `\$_FILES`!";
return false;
}
if (!is_array($optimizedValidationArray) || empty($optimizedValidationArray)) {
$c['err']['FAILED_TO_RUN_VALIDATION_FUNCTION'] = "Validation Function needs a non-empty array for `\$optimizedValidationArray`!";
return false;
}
$allowedSources = ['GET' => [], 'POST' => [], 'JSON' => []];
if (!is_string($source) || !isset($allowedSources[$source])) {
$c['err']['FAILED_TO_RUN_VALIDATION_FUNCTION'] = "Validation Function needs a valid string for `\$source` (\"GET\", \"POST\" or \"JSON\" - uppercase only)!";
return false;
}
$inputData = null;
if ($source === 'GET') {
$inputData = $_GET ?? null;
$c['v_config']['source'] = "GET";
} elseif ($source === 'POST') {
$inputData = $_POST ?? null;
$c['v_config']['source'] = "POST";
} elseif ($source === 'JSON') {
$inputData = json_decode(file_get_contents('php://input'), true);
if (json_last_error() !== JSON_ERROR_NONE) {
$c['err']['FAILED_TO_RUN_VALIDATION_FUNCTION'] = "Validation Function needs a valid decoded JSON string for `\$source`!";
return false;
}
$c['v_config']['source'] = "JSON";
}
if (!is_array($inputData) || empty($inputData)) {
$c['err']['FAILED_TO_RUN_VALIDATION_FUNCTION'] = "Validation Function needs a valid non-empty array for `\$inputData`!";
return false;
}
// TODO: REMOVE THIS LINE WHEN DONE TESTING
// This is just for testing purposes to see the input data
var_dump("TEST DATA(GET/POST/JSON):", $inputData);
$c['v_ok'] = true;
$c['v'] = [];
$c['v_data'] = [];
funk_validation_recursively_improved(
$c,
$inputData,
$optimizedValidationArray,
$c['v'],
$c['v_data'],
);
if ($c['v_ok']) {
$c['v'] = null;
return true;
}
if (
isset($c['v_config']['show_v_data_only_if_all_valid'])
&& $c['v_config']['show_v_data_only_if_all_valid'] === true
) {
$c['v_data'] = null;
}
return false;
}
function funk_use_validation(&$c, $validationHandler, $validationFunction, $source)
Tidigare behövdes det två funktioner för att först ladda in en fil och sedan köra deras funktion men nu kan allt göras med enbart denna simpla enkelrad:
$v_test = funk_use_validation($c, "v_test", "v_test2", "GET");
LLM:er har angett så kallade dispatchers vilket är tänkta att innehålla alla framladdade funktioner när nya filer inkluderats. Om du inte redan vet så leder inkluderande av samma filer inuti PHP till att du får tillbaka boolean istället för att faktiskt få ta del av filens innehåll då tanken är att du redan har den någon annanstans i minnet.
Inuti den globala konfigurationsvariabeln $c gick det då finurligt att ha ['v_handlers']-nyckeln vilket först är tom men kan fyllas med de inkluderade filerna. Varje inkluderad fil är då det instängda funktionsomfånget (eng. "function scope").
Med andra ord kan då varje fils funktioner åkallas via dessa lagrade filfunktioner i en och samma globala konfigurationsvariabel så att säga. Och går det för Validering så kommer det även att gå för SQL-frågeskapande.
Denna "snilleblixt" kom till mig när jag funderade på faktumet att middlewares är endast inkluderade filer i form av returnerade funktioner vilket innebär att i nuvarande lösning så går det bara att köra en middleware-fil en gång sedan är den "förbrukad".
Eller nej, den finns fortfarande kvar i "minnet" så länge namnet på funktionen går att ta reda på så går den att köras om igen troligen eftersom funktionen är då deklarerad?🤔
Från flera steg till bara ett par steg...!
Ett annat (medveten ordvits) - framsteg - är att nu innehåller den huvudsakliga inkluderade filen bara tre steg istället för tidigare fem steg. Dessutom är alla huvudsakliga initieringsfunktioner middlewares som körs innan någon ruttmatchningsfunktion körs.
Lägg märke till att middlewares-mappen nu har tre undermappar. En mapp är det som körs innan någon ruttmatchning äger rum, en annan mapp är den som körs efter att ruttmatchning har ägt rum men själva hanteringsfunktionen för den matchade rutten har inte ännu körts. Den tredje mappen är således det som körs efter att en HTTPS-begäran har hanterats.
Två saker nu:
1) Det är valfritt på ruttmatchningsnivån huruvida någon slags "afterwares" ska köras efter hanterad HTTPS-begäran eller ej. När JSON och/eller HTML returneras så går det att med tydligt funktionsnamn ange i stil med:
// Returnera JSON och AVSLUTA sedan skriptet
return_json_and_exit($c, $json, $code);
// Returnera KOMPILERAD SIDA (html) UTAN att avsluta skriptet
return_page_without_exit($c, $page, $code);
Den första funktionen i koden ovan kommer att köra exit; efter returnerat JSON och valfri statuskod medan den andra funktionen ovanför kommer att fortsätta köra skriptet och därmed eventuella middlewares innan skriptet avslutas.
2) Och detta återkommer till det övre nu: Tack vare övertydliga funktionsnamn så är det svårare att göra fel eller snarare svårare att misstolka. Det ledde till en intressant tanke: eftersom mapparna för middlewares hypotetiskt talat kan ha samma filnamn så skulle det kunna gå att därmed ha samma funktionsnamn på dem då deras funktionsnamn ska motsvara deras filnamn.
I och med detta så finns det en påtaglig risk för Utvecklaren att uppleva otydlighet i konfigurationen av vilka middlewares som körs före ruttmatchning, efter ruttmatchning och före rutthanteringsfunktion, och efter hanterad HTTPS-förfrågan.
Mapparna kan komma att få helt andra namn då det inte framgår riktigt om after_route_match betyder innan rutthanteringsfunktionen körts eller inte. Det val jag har tagit för övrigt är att alla middlewares måste ha unika filnamn och därmed unika funktionsnamn även om de kanske vill kunna köras dubbla gånger under en HTTPS-förfråganscykel.
Exempelvis kanske du vill logga att du påbörjat en HTTPS-förfrågan och sedan kanske du vill logga att du har framgångsrikt avslutat en viss slags HTTPS-förfrågan. Samma fil kommer ej då att kunna köras så tillvida inte det konfigureras att alla körda middlewares samlas i en liknande ['mw_handlers']-nyckel på den globala konfigurationsnivån.
Problemet är då att otydlighetens djävulskap då kan åkallas från ingenstans och få Utvecklaren att kanske för sekunden tvivla på om det är rätt eller fel konfigurerat i de olika middlewares-arrayerna i den huvudsakliga konfigurationsfilen med rutter och förknippade middlewares.
Därför lutar jag starkt mot att tvinga unika filnamn för middlewares vilket då även möjliggör att kunna samla dem i en och samma ['mw_handlers']-nyckel på global konfigurationsnivå och låta Utvecklaren välja om denne vill köra en redan körd middleware igen fast med kanske ny last (eng. "payload").
Sammanslagna middlewares eller inte - det är den aldrig ständiga frågan?
Om du har varit överdrivet investerad i hur detta hobbyprojekt har utvecklats de snart två månader(?) så kanske du känner igen dessa middlewares-namn:
return [
'<CONFIG>' =>
[
'middlewares_before_route_match' =>
[
'm_https_redirect',
'm_run_ini_sets',
'm_set_session_cookie_params',
'm_db_connect',
'm_headers_set',
'm_headers_remove',
'm_start_session',
'm_prepare_uri',
'm_match_denied_exact_ips',
'm_match_denied_methods',
'm_match_denied_uas'
],
'middlewares_after_successful_request' => [],
'no_middlewares_match' =>
[
'json' =>
[],
'page' =>
[],
],
'no_route_match' =>
[
'json' =>
[],
'page' =>
[],
],
'no_data_match' =>
[
'json' =>
[],
'page' =>
[],
],
'no_page_match' =>
[
'json' =>
[],
'page' =>
[],
],
],
'ROUTES' =>
[
'GET' =>
[
'/test/:id' =>
[
'handler' =>
[
'r_test' => 'r_test2',
],
'data' =>
[
'd_test' => 'd_test2',
],
],
'/test2' =>
[
'handler' => 'r_test3',
'data' => 'd_test3',
],
'/test3' =>
[
'handler' => 'r_test5',
],
],
'POST' =>
[
'/test/:id' =>
[
'handler' =>
[
'r_test' => 'r_test2',
],
'data' =>
[
'd_test' => 'd_test2',
],
],
],
'PUT' =>
[],
'DELETE' =>
[],
'PATCH' =>
[],
],
];
Konfigurationsfilen för Middlewares, Rutter & deras Hanteringsfunktioner
Precis!
Det är funktionerna som annars tidigare kördes under steg noll (innan det blev vettigare numerär ordningsföljd) där de mindre olika funktionerna nu fungerar exakt likadant fast är sina enskilda middlewares lagrade givetvis i before_route_match-mappen.
I princip är ['middlewares_before_route_match']-nyckeln det initiala som körs innan någon ruttmatchning försöks och detta går att ändra efter eget måfå. Självfallet finns då en mycket hög risk att någon ny Utvecklare gör fel här i tron om att det är bara att radera alla middlewares där.
Vissa är mycket viktigare än andra. Framförallt de som sätter särskilda ini_sets() och vissa säkerhetsbaserade HTTPS-huvuden. Dessutom kan det bli mycket tokigt med ruttmatchningsfunktionen som behöver en giltigt formaterat URI tack vare m_prepare_uri.
En fundering då har varit att slå samman vissa middlewares som är essentiella för att det hela ska kunna starta konsekvent för majoriteten av Utvecklarna samtidigt som de ska ges den enorma friheten att kunna välja vad som bör köras innan något ruttmatchningsförsök påbörjas.
Eller så kanske det finns en viss "charm" i att kunna se precis alla små - men ytterst viktiga - steg som körs innan huvudnumret i webbapplikationen äger rum?🤔 Det hela har också lite av en kanske (o)trevlig bismak av objektorientering där vi nu har "kapslat" hur den ska bete sig för en given fil.
I princip skulle det gå att modifiera i grunden så det skulle gå att välja andra liknande filer men med andra globalt konfigurerade middlewares i en helt annan körordning; och därmed ett helt annat webbapplikationsbeteende? *hm*
Det här med SQL-frågor och att inte återuppfinna hjulet alldeles för mycket på nytt...
Jag håller nu på med att skriva följande funktioner samtidigt så att de kan agera i samklang:
// Skapa SQL-hanteringsfil och/eller SQL-hanteringsfunktion likt Valideringsfiler & Valideringsfunktioner
function cli_create_sql_file_and_or_handler()
// Konvertera förenklad SQL-text till ren SQL-frågesats, och valfritt en hydrationssats & bundna parametrar vid möjlighet
function cli_convert_simple_sql_query_to_optimized_sql($sqlArray, $handlerFile, $fnName)
Den första fungerar nästan likadant som funktionen för att skapa en Valideringsfil och/eller Valideringsfunktion. Skillnaden här är att för att få ut någon användbar användning av de genererade SQL-filerna och deras funktioner så måste snaran dras åt gällande friheten här - tyvärr!
Först och främst finns det ingen chans i världen att någon skulle vilja försöka lära sig skriva annorlunda SQL-språk bara för att i slutändan få ut en vanlig SQL-sats - då kan de lika gärna skriva den i phpMyAdmin eller liknande SQL-databashanteringssystem för med omedelbar återkoppling om syntax, om diverse databastabeller och/eller databastabellkolumner existerar, och så vidare.
För det andra så måste det gå fort, lättsamt och lättförståeligt till. Ju mer ny(!) syntax att behöva ta hänsyn till, desto mindre tålamod och de PHP-baserade ORM:erna kommer att skratta hela vägen från sina GitHub-repon trots att kanske flera av deras Slutanvändare fortfarande råkar skriva diverse "N+1"-satser.
Således fungerar det så här just nu (ja, jag ska flytta på de två sistnämnda argumenten, det upplevs inte logiskt) när du först skriver i CLI:t:
php funkcli create s test2=>test2 authors,comments select
Så skapas en SQL-hanteringsfil (om den inte redan finns) och dess SQL-hanteringsfunktion:
function s_test2(&$c) // <authors,comments>
{
$DX = [
'<CONFIG>' => [
'<QUERY_TYPE>' => 'SELECT',
'<TABLES>' => 'authors,comments',
'[SUBQUERIES]' => [
'[subquery_example_1]' => 'SELECT COUNT(*)',
'[subquery_example_2]' => '(WHERE SELECT *)'
]
],
'<MER_KOMMER>' => '<HÄR_SNART_OXÅ!>',
];
return array([]);
};
Notera inuti kommentaren vilka tabeller det avser såväl som inuti '<TABLES>'-nyckeln, samt att det framgår vad för slags SQL-fråga det berör: en SELECT-fråga. Detta hjälper till med kompileringssteget och även vad som ska visas och inte.
Först hade jag tankarna om att visa alla möjliga SQL-nyckelord men då skulle Utvecklarna överflödas och även börja fundera på om allt måste användas? Så istället ska du få det begränsade som behövs för en given typ av SQL-fråga.
Exempelvis INSERT-frågan kommer endast innehålla de nödvändiga kolumnerna för den enskilda valda tabellen (jag försöker anamma ACID-principen där varje SQL-fråga ska göra en sak i taget - sedan hur detta ska gå ihop med transaktioner och tillbakarullning är ett framtida monster att bemöta!😱) inklusive de rätta bundna parametrarna så att du i princip bara behöver kompilera så får du en fungerande SQL-sats för att föra in data för en given tabell.
Liknande kommer att ske för UPDATE- & DELETE-satser där i princip bara SET (för UPDATE), WHERE (både UPDATE & DELETE) och FROM (endast DELETE bland dessa två) kommer att finnas för att förenkla vad som ska bara detaljkorrigeras av Utvecklaren innan kompilering.
SELECT-frågor blir däremot mycket intressant och där det största värdet med hela ska finnas: Här får du först alla valda tabellkolumner för dina valda tabeller och utifrån finurliga funktioner när tabeller först läggs in via .sql-filer under schemas-mappen så kan kompatibla JOINs lagras i förhand.
Detta innebär i sin tur att när SELECT-frågor med olika tabeller väljs så kommer det redan finnas alla "inställda" JOINs för dessa tabeller emellan. Det Utvecklaren ska välja då är vilka kolumner från respektive tabell som är av intresse, eventuella WHERE-satser och möjligen - exklusivt för SELECT-frågor - diverse kolumnbaserade aggregationsfunktioner såväl som ORDER, LIMIT & OFFSET.
Frågan är då hur det ska kommuniceras vad som är "obligatoriskt" och vad som är valfritt?🤔 Jag har funderat på att kommentera ut diverse nycklar som inte behövs om de inte önskas. För om de inte ens finns som tillgängliga nycklar så kan det ju bli tolkningen att de inte ens går att använda från första början eftersom de inte finns? (likt hur de inte finns för UPDATE, DELETE & UPDATE...)
Det förhoppningsvis största - och tänkta - värdet med SELECT-frågorna är att snabbt välja det som önskas, slå samman dem och sedan få en snabb datahydreringsfunktion att köra vid behov för att snabbt kunna presentera all data på önskat vis.
En rolig sak som slagit mig för någon månad sedan är att bara för att du slår samman två tabeller med JOIN - exempelvis "författare" och "böcker" - så vet datahydrering inte om du syftar på "Bok där varje författare är en undernyckel", dvs., "böcker med författare" eller om du syftar på "Författare där böckerna är en undernyckel", dvs., "författare med böcker".
Du hämtar alltså "Författare" & "Böcker" där varje författare har ett antal böcker och varje bok tillhör en författare (för enkelhetens skull i detta exempel) men hur du vill presentera all data med dessa två JOINade tabeller är helt och upp till dig att både besluta och sedan förverkliga med hjälp av lämplig datahydreringsteknik!
Gällande datahydreringsteknik så ser jag mig framför två alternativ:
1) Datahydrering med två loopar där första loopen är för varje rad av data på kolumnnivå och sedan andra loopen går då igenom varje kolumn och kollar om den redan finns på rätt nyckelnivå eller inte och sedan stoppar in den på rätt plats under den så kallade variabeltilldelningen.
2) Datahydrering med bara en loop då det är hårdkodat redan vart data ska stoppas - dvs., variabeltilldelandet är hårdkodat genom att den vet redan tabellkolumnerna. Mångmiljonfrågan är vad detta får för eventuell prestandavinst eller om det är magsjukeinducerande mikrooptimeringstrams om någon Databassenior skulle se denna datahydreringsteknik?😂
Vidareutbildning
Inget nytt att rapportera mer än att jag sett följande YT-klipp om rekursion:
Klippet håller mycket hög kvalité och hoppar mellan rekursion och iteration i hur funktioner kan skrivas för att på så vis förstå deras för- och nackdelar (och/eller kompromisser).
Även andra YT-klipp från denna så kallade "CodeTuber" håller mycket god kvalité enligt mig!🫡
Jag har ju varit smått sugen att få till den rekursiva valideringsfunktionen till en iterativ sådan, men absolut inte på ett hyfsat bra tag då rekursionsdjupet måste gå väldigt djupt för att orsaka problem vilket i sin tur också betyder enormt nyckeldjup i data som ska valideras.
Då ställs frågan om inte data ska ompaketeras på ett mer lätthanterligt vis för att förebygga sådana rekursionsdjupsrisker från allra första början istället?😬
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
Jag småstädade lite i gamla skåp och fann min 2017-kalender där jag såg att jag då vägde runt 72-73 kg medan jag idag väger mellan 77-78 kg.
Absolut ingen katastrof men jag har tidigare vägt runt 65-70 kg när jag var runt 16-19 år gammal. Större delen av fettet sitter i buken (inte bra!) och lite i ansiktet ("köttbullsansikte")!
Som tur var har jag följande tisha i bilden ovan vilket jag ska börja använda på gymmet i kombination med dagligt proteinpulver i förhoppningen att "datatransformera" större delen av den där vikten till muskler💪 istället för fett🧈.
Jobb & Uppdrag
🪦Vila i frid tills vidare tidigare Uppdragsgivare(?)🪦
För några dagar sedan skrev jag om den tidigare Uppdragsgivaren jag har haft i nästan fem års tid och hur det samarbetet har lagt på is i och med att Uppdragsgivaren hoppas på att kunna ersätta det jag tillhandahållit manuellt med hjälp av AI gällande inläsning av PDF-filer och sedan kategorisering av dess innehåll.
Frågan är hur mycket av detta kommer att tillföra annan slags nödvändig manuell mänsklig handpåläggning och om kostnaden i tid (och därmed pengar) kommer att vara värt det. Den som lever och bryr sig kommer att förr eller senare att få svar på den frågan!
Det är ju smått lustigt att - fortfarande i skrivande stund - ha blivit ersatt av LLM:er när jag samtidigt känner till dess både styrkor såväl som uppenbara svagheter och nackdelar.
Till och med OCR-algoritmer är riktigt usla på att läsa in texter från PDF:er och det största problemet, likt med LLM:er är att du inte blir tillsagd om "Här kanske det blev fel" utan du måste i princip "lusläsa" igenom för att hitta eventuella "statistiska misstag".
Nåja, nog om det "jobbgnället" nu!
🤔Vem vill egentligen bli känd för detta ute på stan?🤔
En annan sak för några dagar sedan var att en person på UpWork bjöd in mig flera gånger till intervju (=det är alltid först intervju för ett jobb du kan ha sökt eller om Uppdragsgivare där bjudit in dig manuellt; du accepterar intervjun, sedan accepterar du kontraktet, du påbörjar och levererar det, Uppdragsgivaren godkänner efter kanske vissa revisioner och sedan får du betalt in på kontot som går att plocka ut efter ett par arbetsdagar).
Först bjöd personen in mig för ett jobb på $ 30 vilket jag avböjde, senare $ 40 vilket jag också avböjde. Sedan i förrgår(?) fick jag ett erbjudande på $ 100 vilket höjde mina ögonbryn av måttligt intresse. Det hela handlade om så kallad "Mystery Shopping" vilket i sig är lite udda kan jag tycka.
Personligen känner jag till fenomenet men har aldrig utfört sådana slags uppdrag och jag är fullt medveten om olika kopplade bedrägerier till dessa: exempelvis du får för mycket betalt för något och ombes att betala tillbaka men istället öppnas dispyt mot dig där du blir av även med mellanskillnaden i slutändan (=bedragaren går med "vinst").
Å ena sidan kände jag att behövde ta Uppdraget för de "enkla pengarnas skull". Samtidigt kände jag att det inte riktigt var värt det hela för jag behövde ta mig in till en annan del av staden med hjälp av cykel eller buss vilket kostar pengar i rådande "intäktsbefriade livssituation" (det var en jädrans eufemism?😂).
Sedan fick jag reda på från Uppdragsgivaren via UpWork att vad som krävdes var besök hos några elektroniska butiker nere på stan inklusive fototagande av diverse delar av en Apple-affär i form av en slags granskning (eng. "audit").
Nackdelen såsom jag såg det var att bilderna skulle behöva granskas och beviljas av Uppdragsgivarens slutkund (troligen någon lång kedja av folk med koppling till Apple) och jag skulle alltså teoretiskt talat ha kunna behöva åkt in igen för att ta nya bilder och därmed kostat mer tid, pengar och självrespekt än vad jag gått med på.
En annan uppgift i det hela var att jag skulle gå in på ett par elektroniska butiker och agera som köpare av en bärbar dator och/eller en surfplatta och sedan skulle jag ha gått in på Uppdragsgivarens webbplats (vilket ligger utanför UpWork - varningsflagga här(!)) för att fylla i något formulär.
I princip hade jag kunna blivit "den där personen som springer runt och låtsas vara kund för pengarnas skull" ute på stan vilket inte precis är den största här i Sverige. Uppdragsgivaren på UpWork sa sedan att det var brådskande med deadline redan på torsdag (dvs., igår) men jag avböjde det hela och sa att jag upplevde att jag inte kunde garantera för både dem och mig själv att jag skulle kunna göra rätt från början utan att behöva gå utanför tid- & självrespektbudgetten.
🎯✒️❤Konsten att skriva så det träffar rakt i hjärtat!❤️✒️🎯
Jag vet vad du kanske tror nu med alla dessa emojis i dessa underrubriker: "Har snubben blivit chatGPT?". De används som visuella hjälpmedel för att vägleda ögat för vad som är underrubriker till de huvudsakliga rubrikerna.
Som sagt var så skrev jag för några dagar sedan om det potentiella avslutade samarbetet mellan mig och min nästan femårigt långa Uppdragsgivare (det är hypotetiskt möjligt att Uppdragsgivaren återkommer redan någon gång efter sommaren om de upplever mer problem än kostnadssänkande effekter av deras så kallade "AI-satsning") så skrev jag om detta på flera platser.
I en Slack-grupp skrev jag om det och sättet jag formulerade då om min färska Juniora Fullstacks-Webbutvecklar-bakgrund var att istället för att säga att "Jag kan X, Y, Z inom webbutveckling" så skrev jag, "Jag har varit i kontakt med X, Y, Z inom webbutveckling".
Mina nämnda styrkor blev/är backend och gällande den sociala biten skrev jag en viktig sak (anser jag): "Jag har inget 'ego' i det jag gör". Sistnämnda innebär att jag har inget emot att ha fel, för jag vill inte ha rätt, jag vill veta/lära mig rätt.
En social bromskloss är ju "garanterat" personer vars "egon" krockar med lagets mål inom samarbetsbaserade utvecklingsjobb? Jag tänker att det blir onödigt långa diskussioner om saker och ting som inte överenskommes såväl som om något "ego" är beslutsfattande så kan det verkligen bli friktionsmässigt långsamt arbetande inom vissa arbetsgrupper?🤔
Hursomhelst, en person skrev senare till mig privat i en Slack-grupp att personen gillar min inställning och skulle höra av sig vid tillfälle om personen skulle vara vid behov av utvecklare vid nya och/eller pågående projekt.
Roligt att åtminstone kunna skriva något som kan kommunicera det jag vill få kommunicerat: "Jag kan något men påstår absolut inte att jag kan allt och jag vill hellre lära mig rätt än att ha rätt och jag har inget ego kring det jag gör så i arbetsgrupper har jag lättare att agera som 'socialt glidmedel' än en 'bromskloss'!".
Hobbyprojekt
(När du läser härifrån så sitter jag just nu i fredagens pågående Kodfika med start kl15:00 - lite små kul eller inte alls! XD)
🔁Den återanvändbara WHERE-funktionen?🔁
Följande funktion kan nu användas av alla de olika SQL-frågorna (INSERT, UPDATE, DELETE & SELECT):
function cli_parse_where_clause_sql($tbs, $where, $queryType, $sqlArray, &$builtBindedParamsString){}
Funktionen tar en sträng men omvandlar den sedan till en array för att bryta ned utifrån varje |-symbol vilket kan bli problematiskt om den bitvisa |operatorn används. Den behöver även känna till vad för slags SQL-frågan den hanterar (INSERT, UPDATE, DELETE eller SELECT), vilka tabeller det gäller såväl som alla nuvarande inlagda tabeller.
Efter klassisk parametervalidering så börjar den - för varje WHERE-del fördelat på |-symbolen - att kontrollera om det finns särskild startsyntax såsom nyckelorden AND, BETWEEN, IN med flera och dessa får WHERE-satsen inte börja med men den får innehålla dem dock.
Sedan så finns följande Regex:
$wPartRegex = '/^([()=A-Za-z_\-0-9:]+)\s+([+\-*\/%=&|^!<>]+|ALL|AND|BETWEEN|EXISTS|IN|LIKE|NOT|SOME)\s+(.*)$/';
Den körs efter att särskilda specialfall först har hanterats och den kommer att utökas för att också kunna skilja på [Subqueries] vilket just nu inte stöds utan då blir det ingen matchning. Sedan kan den hämta ut de matchade delarna:
$mCol = $wMatches[1] ?? null;
$mOperator = $wMatches[2] ?? null;
$mValue = $wMatches[3] ?? null;
En QoL-sak jag har lagt in är en varning när operatorn för en given WHERE-del inte är = vilket betyder att SQL-frågor såsom DELETE & UPDATE kan komma att påverka fler än en rad i en vald tabell:
if ($mOperator !== '=' && ($queryType === 'DELETE' || $queryType === 'UPDATE')) {
cli_warning_without_exit("[cli_parse_where_clause_sql]: WHERE Clause Part: \"$wPart\" in Query Type: \"$queryType\" has an Operator that is NOT `=`!");
cli_info_without_exit("This could lead to affecting more Table Rows than desired unless you really want that!");
}
Sedan har vi två fall för varje WHERE-del som ska hanteras:
1. Är det bara en tabell som skickades med?
2. Eller är det flera tabeller som skickades med?
if ($singleTable){}
else{}
Vad som görs innan en WHERE-del läggs in i WHERE-satssträngen som till sist skickas tillbaka om inget felmeddelande har stoppat hela konverteringen är att först kontrollera att alla tabellkolumner och tabeller angivna inuti den nuvarande WHERE-delen existerar för du kan ju inte göra en SQL-fråga mot icke-existerande tabellkolumner och/eller tabeller, eller hur?
Rätt datatypbindning hämtas vilket behövs till SQL-bind_params()-metoden när ?-tecken ska ersättas med korrekt typ av data vid en given SQL-fråga. Och om det är hårdkodat värde istället så kontrolleras det att det är av rätt datatypbindning annars stoppas det hela av felmeddelande.
Men är allt frid och fröjd så byggs $parsedWhere-strängen ut med tabellen och/eller kolumnerna såväl som dess giltiga operator och hårdkodade värde eller?-tecken. Sedan fortsätter det hela tills att hela WHERE-satssträngen har hanterats och returnerats till den fullständiga SQL-strängen.
Det är några specialfall att behöva hantera här och var såväl som tilläggen av mellanslag här och var vilket är lite oregelbundet här vilket gör att ord kan sitta ihop vilket då skapar en ogiltig SQL-fråga.
På tal om (o)giltiga SQL-frågor så är det följande del i kompileringsfunktionen, det vill säga function cli_compile_dx_sql_to_optimized_sql():
// This contains the optimized SQL Query which will then replace the "$matchedReturnStmt"
// The function can error out on its own so we do not need to check for the return value!
$optimizedSQLArray = cli_convert_simple_sql_query_to_optimized_sql($evalCode, $handlerFile, $fnName);
// We validate the optimized SQL Query String by using the Prepared Statement that should not fail
// If it fails, we will catch the exception and inform the Developer. It could fail due to actual
// invalid SQL String Syntax or because of a mismatch between the Table Configuration in `tables.php`
// and the actual Table in the MySQL DBMS (e.g. phpMyAdmin, Adminer, etc.) assuming it exists!
$dbConnect = cli_db_connect();
$queryToTest = $optimizedSQLArray['sql'] ?? null;
if ($queryToTest === null || !is_string_and_not_empty($queryToTest)) {
cli_err_without_exit("The optimized SQL Query is Empty or NOT a Valid String in SQL Function \"$fnName\" in \"$handlerFile.php\".");
cli_info("Check if indeed the `sql` key was provided from the returned Optimized SQL Array Variable?");
}
try {
cli_info_without_exit("Testing the Optimized SQL Query String from SQL Function \"$fnName\" in \"$handlerFile.php\".");
$stmt = $dbConnect->prepare($queryToTest);
} catch (mysqli_sql_exception $e) {
cli_err_without_exit("The Optimized SQL Query String FAILED during Statement Preparing (from SQL Function \"$fnName\" in \"$handlerFile.php\").");
cli_info_without_exit("This means either\n1) Actual invalid SQL String Syntax that somehow slipped through the Compilation Stage when it shouldn't have, or that \n2) The Table and its configuration added in `config/tables.php` DOES NOT MATCH the Table with the same name in your local MySQL DBMS (e.g. phpMyAdmin, Adminer, etc.) assuming it exists!");
cli_info("Internal MySQLi Error: \"" . $e->getMessage() . "\"");
}
cli_success_without_exit("The SQL Query String in SQL Function \"$fnName\" in \"$handlerFile.php\" was Successfully Validated with 0 Errors When Sending it Prepared to the local MySQL DBMS!");
cli_info_without_exit("Attempting adding the entire Optimized SQL Array as the returned value in SQL Function \"$fnName\" in \"$handlerFile.php\"!");
som ansluter till lokala MySQL-databasen och sedan provar att skicka en så kallad förberedande SQL-sats (eng. "prepared statement"). En sak jag inte insåg här är att syntaxen kan vara korrekt fast SQL-frågan kommer att misslyckas på grund av hur det är konfigurerat i databasen eller vilka data som egentligen skickas med i samband med SQL-frågan (t.ex. en primär- och/eller referensnyckel som inte finns).
🗊Hur mycket är kod och hur mycket är kommentarer?!🗊
Avslutningsvis för denna gång - och det är i skrivande stund 25 minuter i Kodfikat just nu - så tog jag mig tillfället i akt att räkna antalet kommentarer kontra kod i den största filen just nu: cli_funs.php.
6963 rader av kod, kommentarer och/eller radbrytningar.
1368 rader som börjar med kommentarstecknen // (/* */ används ej i denna fil).
5595 rader av faktisk kod, hur långt eller kort det må vara, och ibland radbrytningar.
Räknar vi då på: 1368 / 6963 = 0,1964 så får vi alltså att cli_funs.php-filen just nu innehåller nästan en femtedel i form av bara kommentarer(!) Vissa kanske älskar detta och andra får magsjuka, huvudvärk och känningar i kroppsdelar de aldrig tidigare har fått känningar i!
Vidareutbildning
För någon dag eller två sedan såg jag följande YT-klipp som handlar om en studie från Apples mjukvaruingenjör med fokus på AI/LLM:er:
I princip "sågas" hajpen om att LLM:ers så kallade "tänkande" eller "resonemang" skulle vara likställt det människor gör och att det hela egentligen emuleras i form av ord. Liknande har jag resonerat kring LLM:ers så kallade "tänkande/resonemang".
De förutser statistiskt talat nästa ord i en följd av ord utifrån vad dess träningsdata innehåller vilket skulle representera någon form av "tänkande" eller "resonemang". Vidare visade YT-klippet resultat från Apples studie av populära LLM:er och hur de misslyckades med sitt "tänkande" eller "resonemang" ju mer komplext något blev trots att lösningen egentligen var endast rekursiv i sin natur.
Exemplet var Hanoi-tornet och antalet cirklar du använde dig av. Efter ett visst antal så misslyckades alla populära LLM:er med sitt "tänkande" eller "resonemang" trots att de borde via "emergenta beteenden" borde ha kunna extrapolerat fram den optimala rekursiva funktionen oavsett ökad komplexitet i Hanoi-tornet.
(Nu är jag ~40 minuter inne i Kodfikat - så där får du lite halvfacit på den tid det ibland tar att skriva!)
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"
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Senast redigerat
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Webbutvecklingsdagbok - efter studierna
En kombination av insikt av bättre SecOps, och/eller lathet(?)/energieffektivisering(?) har fått mig att inse att underrubriken om hälsan är av personlig natur plus att denna tråd handlar om Webbutveckling och inte någon slags "textbaserad Instagram" om mitt liv. Du vill läsa om Webbutvecklingsrelaterat innehåll, eller hur? Varför ska Du då behöva se någon annans personliga träningsdagbok?!🤔
Du kanske följer vissa YT-kanaler där vissa saker älskar Du att titta på medan annat avskyr du. Jag brukar titta på klipp från en YT-kanal vars skapare reagerar på den animerade versionen av One Piece där jag redan har sett det mesta (såg senaste avsnittet idag).
Men samma YT-kanal publicerar massor av annat de reagerar på som jag bryr mig noll om. Därför följer jag inte kanalen utan ser bara vissa dagar i veckan när särskilda klipp dyker upp i rekommendationsflödet för att YT otroligt(?) nog vet vad jag vill se från vilka och när!
Liknande upplevelse kanske Du fick när du helt plötsligt såg rubriken "Hälsa"?😜 Därmed så kommer du aldrig mer att se den i just denna tråd här hos Sweclockers!
(Jag kan däremot - som ett avsked till den underrubriken - berätta att samma vecka från förra gångens rapportering här så genomförde jag benpasset, följt av flertalet promenader följande dagarna därpå!🫡)
🖥️ Jobb & Uppdrag
Jag har fått återkoppling från personen jag träffade vid DragonTech för numera länge sedan. Icke-förvånande nog så har bolaget där personen arbetar gått vidare med andra (och förhoppningsvis mer kvalificerade) kandidater gällande en Utvecklingsroll.
Igår fick jag ett DM om ett potentiellt jobb för en person som verkar ha "vibbkodat" fram en React Native-baserad app som samtidigt tycks krascha en hel del. Det lär ju vara roligt att felsöka en sådan mobilapp utan att ha varit från grunden där du till 99 % kan vara säker på massa "Jaha, se där ja..!."-reaktioner när du går igenom den statistiskt sannolika "vibbkodade" koden...
Om Du hoppar in i primärt "människokodade" projekt så kan du åtminstone få en känsla för vad som tycks kunna ha varit skrivet av vem i och med "personliga kodstilar" som kan dyka fram genom semantisk frekvensanalys. Jag påstår inte att detta per automatik gör alla människoprojekt bättre än alla "vibbkodade" projekt.
Hursomhelst så verkar detta potentiella jobb inte ha några pengar och då blir det ju likadant som om jag fortsatte med mitt så kallade "hobbyramverk" i syftet att ta fram en portfölj. Det går nog dock samtidigt att argumentera att det förstnämnda möjligen skulle väga tyngre som framtida referens.
🌐 Hobbyprojekt
SQL-Stränggenerering för SELECT äntligen "tillräckligt färdig"!
I nedanstående finner Du exempel på hur en SQL-fråga först genererades med:
php funkcli create s test2=>test5 s author,articles,comments
Och sedan kompilerades med följande kommando två gånger efter att ha rättat efter felmeddelande:
php funkcli compile s test2=>test5 s authors,articles,comments
[FunkCLI - INFO]: Found "$DX" variable parsed as a valid PHP Array!
[FunkCLI - SYNTAX ERROR]: Table `articles` is already marked as joined in `JOINS_ON` Key in SQL Array `s_test2.php=>s_test5` for SELECT Query!
[FunkCLI - INFO]: You can only join a Table once in the `JOINS_ON` Key! (based on `tables.php` File)
[FunkCLI - INFO]: Current Joined Tables are: `authors`->`articles`->`comments`!
Vid lyckad kompilering så syns följande:
[FunkCLI - INFO]: Found "$DX" variable parsed as a valid PHP Array!
[FunkCLI - WARNING]: The `<HYDRATION>` Key in SQL Array `s_test2.php=>s_test5` for SELECT Query Type was NOT set or is Empty! (or invalid Data Type - no attempt were made to parse it due to invalid Data Type; must be an Array)
[FunkCLI - INFO]: Hydration will not be applied to the results of this query!
[FunkCLI - SUCCESS]: Built SQL String: `SELECT authors.id AS authors_id, authors.name AS authors_name, authors.email AS authors_email, authors.description AS authors_description, authors.longer_description AS authors_longer_description, authors.age AS authors_age, authors.weight AS authors_weight, authors.nickname AS authors_nickname, authors.updated_at AS authors_updated_at, articles.id AS articles_id, articles.author_id AS articles_author_id, articles.title AS articles_title, articles.content AS articles_content, articles.published AS articles_published, articles.created_at AS articles_created_at, articles.updated_at AS articles_updated_at, comments.id AS comments_id, comments.article_id AS comments_article_id, comments.content AS comments_content, comments.author_id AS comments_author_id, comments.created_at AS comments_created_at FROM authors INNER JOIN articles ON authors.id = articles.author_id INNER JOIN comments ON authors.id = comments.author_id;`
[FunkCLI - INFO]: Testing the Optimized SQL Query String from SQL Function "s_test5" in "s_test2.php".
[FunkCLI - SUCCESS]: The SQL Query String in SQL Function "s_test5" in "s_test2.php" was Successfully Validated with 0 Errors When Sending it Prepared to the local MySQL DBMS!
[FunkCLI - INFO]: Attempting adding the entire Optimized SQL Array as the returned value in SQL Function "s_test5" in "s_test2.php"!
[FunkCLI - SUCCESS]: SUCCESSFULLY COMPILED SQL Query to Optimized SQL in SQL Function "s_test5" in "funkphp/sql/s_test2.php".
[FunkCLI - INFO]: IMPORTANT: Open it in an IDE and press CMD+S or CTRL+S to autoformat the SQL Handler File again!
Med följande kod (majoriteten av kommentarer borttagna):
function s_test5(&$c) // <authors,articles,comments>
{
$DX = [
'<CONFIG>' => [
'<QUERY_TYPE>' => 'SELECT',
'<TABLES>' => ['authors', 'articles', 'comments'],
'<HYDRATION_MODE>' => 'simple|advanced',
'<HYDRATION_TYPE>' => 'array|object',
'[SUBQUERIES]' => [
'[subquery_example_1]' => 'SELECT COUNT(*)',
'[subquery_example_2]' => '(WHERE SELECT *)'
]
],
'FROM' => 'authors',
'JOINS_ON' => [
'inner=articles,authors(id),articles(author_id)',
'inner=comments,authors(id),comments(author_id)',
],
'SELECT' => [
'authors:id,name,email,description,longer_description,age,weight,nickname,updated_at',
'articles:id,author_id,title,content,published,created_at,updated_at',
'comments:id,article_id,content,author_id,created_at',
],
'WHERE' => '',
'GROUP BY' => '',
'HAVING' => '',
'ORDER BY' => '',
'LIMIT' => '',
'OFFSET' => '',
'<HYDRATION>' => [],
'<MATCHED_FIELDS>' => [
'authors_id' => '',
'authors_name' => '',
'authors_email' => '',
'authors_description' => '',
'authors_longer_description' => '',
'authors_age' => '',
'authors_weight' => '',
'authors_nickname' => '',
'authors_updated_at' => '',
'articles_id' => '',
'articles_author_id' => '',
'articles_title' => '',
'articles_content' => '',
'articles_published' => '',
'articles_created_at' => '',
'articles_updated_at' => '',
'comments_id' => '',
'comments_article_id' => '',
'comments_content' => '',
'comments_author_id' => '',
'comments_created_at' => ''
],
];
return array(
'sql' => 'SELECT authors.id AS authors_id, authors.name AS authors_name, authors.email AS authors_email, authors.description AS authors_description, authors.longer_description AS authors_longer_description, authors.age AS authors_age, authors.weight AS authors_weight, authors.nickname AS authors_nickname, authors.updated_at AS authors_updated_at, articles.id AS articles_id, articles.author_id AS articles_author_id, articles.title AS articles_title, articles.content AS articles_content, articles.published AS articles_published, articles.created_at AS articles_created_at, articles.updated_at AS articles_updated_at, comments.id AS comments_id, comments.article_id AS comments_article_id, comments.content AS comments_content, comments.author_id AS comments_author_id, comments.created_at AS comments_created_at FROM authors INNER JOIN articles ON authors.id = articles.author_id INNER JOIN comments ON authors.id = comments.author_id;',
'hydrate' =>
array(
'mode' => 'simple',
'type' => 'array',
'key' => NULL,
),
'bparam' => '',
'fields' =>
array(),
);
};
s_test2 => s_test5 - Exempel på CLI-genererad & kompilerad SELECT-fråga! (s_test2.php)
Som Du ser först i CLI:t så får du gott om information om problematik såväl som när något försöks och sedan om det lyckas eller inte, såväl som diverse varningar här och var. På grund av att filerna ändras direkt inuti IDE:t så uppmanas Du alltid efter sådana slags filmanipuleringar via CLI:t att öppna filen och spara den igen så att "Prettier" och/eller inbyggda Lintern(?) i IDE:t gör sitt att indentera kodraderna utifrån blocknivå.
När jag läste på mer om SQL så fick jag lära mig att exekveringsordningen av SQL-frågor faktiskt börjar med FROM och JOIN (när & där det är applicerbart) innan INSERT, DELETE, UPDATE eller i detta fall SELECT. Så $DX-variabeln följer den ordningen efter konfigurationsnyckeln "<CONFIG>" för att det ska logiskt gå att följa exekveringsordningen av en given SQL-fråga (vid SELECT främst).
Funktionen function cli_parse_joins_on_DFS($fromTb, $availableTableNames, $relationships){}; används för att ta fram vilka tabeller har vilka relationer med vilka andra tabeller. På tal om det: Om Du minns tables.php-filen där alla tabeller läggs till som en slags "Ground Truth" för alla CLI-kommandon när du vill arbeta med att så hade jag en nyckel där vid namn 'relationships' som jag först aldrig visste vad jag skulle ha till.
Sedan när jag blev tvungen att kunna erbjuda automatiska förslag på vilka tabeller som kan slås samman vid FROM+JOIN-stegen så fick jag förslag från Gemini 2.5 Flash Thinking att skapa något i stil med detta:
'relationships' =>
[
'authors' =>
[
'articles' =>
[
'local_column' => 'id',
'foreign_column' => 'author_id',
'local_table' => 'authors',
'foreign_table' => 'articles',
'direction' => 'pk_to_fk',
],
],
'articles' =>
[
'authors' =>
[
'local_column' => 'author_id',
'foreign_column' => 'id',
'local_table' => 'articles',
'foreign_table' => 'authors',
'direction' => 'fk_to_pk',
],
],
'alones' =>
[],
],
Notera hur tabellen 'alones' (vars namn är 100 % med flit) är helt tom då den saknar faktiska relationer. En tabell har en eller flera relationer men en nackdel just nu med denna datastruktur är att den inte tillåter (men det går nog att möjliggöra med mer kod) att en tabell hänvisar till fler än en sekundärnyckel till en annan tabell.
Detta sistnämnda är dock dålig Databasstruktur anser jag: I princip om du skulle ha två olika sekundärnycklar från en tabell till sedan en och samma andra tabell så innebär det att du alltid måste stoppa in data åt två olika sekundärnycklar till samma tabell från en annan tabell? Vad händer då om du inte har data för tillfället till ena sekundärnyckeln men andra och du vill få övrig data instoppad så den inte går förlorad?!
Typexempel på dålig datamodellering(?) även om det enligt Gemini 2.5 Flash Thinking 100 % går att göra så här utan att MySQL skulle klaga på det. Faktumet att jag först inte ens trodde på det för jag bara "kände" att det kändes helt fel slags datastruktur tycker jag är ett gott tecken på mitt tänkande med normalformer och normalisering som det så (o)fint heter inom databasvärlden!
Så är JOINS_ON tänkt att fungera!
När du läser SELECT-nyckeln så ser det nog rätt så logiskt ut. Först har du tabellnamnet och sedan kolumnerna från den.
Alternativa skrivsätt per tabellnivå är följande (felmeddelande ges om tabellen och/eller någon enskild kolumn saknas från tabellen ifråga):
'SELECT' => [
'authors:id,name', // Välj endast "id" och "name"
'articles!:id', // Välj alla kolumner men exkludera "id"-kolumnen
'comments',], // Välj alla kolumner från tabellen
Första tabellen så får du alltså endast kolumnerna id och name medan andra tabellen väljer alla kolumner samtidigt den exkluderar id-kolumnen. Tredje tabellen så väljs alla kolumner. Det går även att skriva in aggregeringsfunktioner direkt i SELECT-nyckeln vars alias kan hänvisas till i HAVING-nyckeln:
'SELECT' => [
'authors:id,AVG(age)',], // Välj endast "id" och snittvärdet för "age"
Däremot om du skriver aggregatfunktioner i WHERE-nyckeln så blir det felmeddelande då det tydligen inte är tillåtet. Nycklarna GROUP BY och HAVING var riktigt kluriga även om HAVING i princip kunde återanvända en hel del från WHERE med tillägget av att tillåta aggregatfunktioner i uttrycken.
Så här ser egentligen JOINS_ON-nyckeln ut när du "schavottar" (eng. "scaffolding") för de tre tabellerna:
'FROM' => 'authors',
'JOINS_ON' => [ // Optional, make empty if not joining any tables!
'inner=articles,authors(id),articles(author_id)',
'inner=comments,authors(id),comments(author_id)',
'inner=articles,comments(article_id),articles(id)'],
Jämför med bilden nedan:
Notera ett problem nu i den "schavottade" JOINS_ON-nyckeln.
Du slår först samman authors med articles och sedan comments med authors men sedan articles med comments vilket du inte får göra. Däremot om du tar bort en av de inner=articles så blir allt fröjd igen. Detta är möjligt tack vare funktionen som använder Depth First Search-algoritmen (jag trodde först jag skulle behöva någon slags topologisk sortering istället) som nyttjar relationships-nyckeln i tables.php-filen för att veta vilka tabeller som kan slås samman och så fort ett "par" har slagits samman så får det inte upprepas.
Sedan blir det upp till Utvecklaren att välja vilka tabeller som bör slås ihop och i vilken ordning. Exempelvis följande genererade SQL-sträng:
SELECT authors.id AS authors_id, authors.name AS authors_name, authors.email AS authors_email,
authors.description AS authors_description, authors.longer_description AS authors_longer_description,
authors.age AS authors_age, authors.weight AS authors_weight, authors.nickname AS authors_nickname,
authors.updated_at AS authors_updated_at, articles.id AS articles_id, articles.author_id AS articles_author_id,
articles.title AS articles_title, articles.content AS articles_content, articles.published AS articles_published,
articles.created_at AS articles_created_at, articles.updated_at AS articles_updated_at, comments.id AS comments_id, comments.article_id AS comments_article_id, comments.content AS comments_content,
comments.author_id AS comments_author_id, comments.created_at AS comments_created_at
FROM authors INNER JOIN comments ON authors.id = comments.author_id
INNER JOIN articles ON comments.article_id = articles.id;
Fungerar otroligt nog när nedersta inner-strängelementet tas bort från JOINS_ON-nyckeln:
(Ja, du har 100 % rätt - faktumet att SQL-frågan är bara en lång rad är fruktansvärt för den som vill kunna lusläsa/granska den efter kompilering! Helt klart ett I-landsproblem att lösa senare!)
Några sista ord om JOINS_ON-nyckeln för denna gång är att den kanske upplevs mer komplex än vad den är tänkt att vara. En annan sak är att notera syntaxen för kolumnerna som används och hur det också reflekterar hur det är tänkt att lägga in tabellerna i ramverket:
authors(id),articles(author_id)
authors(id),comments(author_id)
comments(article_id),articles(id)
När en tabell läggs in så bör dess primärnyckel heta bara id medan alla sekundärnycklar bör heta i stil med entitetens singulära namn och sedan _id. Faktum är att när en tabell läggs in via en funktion som läser in en .sql-fil så lägger den till s för att göra namnet engelskt plural även om tabellnamnet inte är i det språket.
Detta saknas nu för just SQL-kompileringen!
Följande saknas än så länge i SQL-kompileringen:
Inre SQL-frågor (eng. Subqueries) stöds men då måste Utvecklaren manuellt lägga till det bundna datatypvärdet i 'bparam' och vilket validerat datafält i 'fields' som ska användas för varje ?-tecken i den ordning de förekommer i SQL-frågan i förhållande till 'fields'-arrayen.
Ingen datahydreringsstruktur finns ännu i 'hydrate'-nyckeln mer än vilken typ som ska skrivas i '<HYDRATION>' => [], och om data ska hydreras i form av objekt eller arrayer. Så det är nyckeln jag ska fixa härnäst. Får jag till det halvhyfsat likt att du bara kan skriva "authors=>articles=>comments" så tror jag att det ger att starkt mervärde. Det ser också bekant ut då likt med with-kedjandet i ORM-varianterna.
🎓 Vidareutbildning
Jag ska titta mer och jag har tittat på så kallde Parsers och dessa tycks börja med "lexers/tokenizing" där du vill kategorisera varje tecken likt du kategoriserar svenska ord i exempelvis olika ordklasser. Sedan när du har gjort det så kan du via din egen Parser bygga upp ett så kallt Abstrakt Strukturträd (eng. "AST") vilket du sedan bearbetar för att slutföra kompileringen.
Det finns några intressanta saker att överväga med tokenizers. Å ena sidan bör de vara kontextlösa genom att inte försöka göra mer än att bara kategorisera tecken. Å andra sidan bör de även inte tillåta fullständigt trasig text att ens få "tokeniseras" färdigt.
Klassikern är när den upptäcker att en sträng börjar via enkel- eller dubbelfnutt men den når slutet och ingen enkel- eller dubbelfnutt syns vilket betyder att en sträng aldrig egentligen "fullbordades" under tokeniseringssteget.
Men kontextlöst fungerar ju inte riktigt: Ska < kategoriseras som en operator, en öppningstagg eller kanske till och med ett okänt tecken? En viss nivå av domänspecificitet behövs till tokenisern utan att överdriva så att den blir prestandaeffektiv sett till tid och minnesanvändning.
När jag läste på en hel del om detta i samband med regex-galenskaperna jag själv har implementerat (och blivit lite bättre på regex - lookahead och lookaback är fortfarande kluriga vilket verkar vara nästan som att skriva in if/elseif/else-satser som en oneliner?!) så insåg varför SQL-frågan oftast börjar med nyckelordet SELECT/INSERT/UPDATE/DELETE (eller kanske systemkommando) fast exekveringsordningen för just en SELECT inte börjar med SELECT utan FROM och JOIN.
En bra start på en mycket simpel men tillräckligt användbar Parser vore just för hur rutter får skrivas innan de läggs i ruttfilen. Giltiga tecken är i princip: /^[a-zA-Z_\-0-9:/]+$/i. När "/:" skrivs så måste det följas av [a-zA-Z0-9]+ medan ingen ny ":" får skrivas. Så grammatiken är väldigt simpel, det vill säga, den själva faktiska "parsingen" som måste göras efter "tokeniseringen".
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 | Del 1 av 3
Fram med valfri läskande dryck och goda tillbehör för nu blir det en rejäl uppdatering med det största fokuset på hobbyprojektet - det 99 % funktionsbaserade PHP-ramverket där resterande procenten är mysqli-objektet av pragmatiska skäl tills vidare - i och med rådande ledighetsmånader så det är mer eller mindre omöjligt att söka jobb och/eller uppdrag såväl som faktumet att jag har inget att komma med ännu (portfölj) tills lanseringen av hobbyprojektet.
🖥️ Jobb & Uppdrag
Inga nya jobb och/eller uppdrag erhållna. För ett par dagar sedan fick jag inbjudan på UpWork att gå med något slags internt talangteam inom "Swedish voiceover". Även om jag kommer att inom kort etablera mig med ljud- och videoklipp här och var på internet så är jag mil från att kunna vara någon svensk rösttalang. Så jag fick tacka nej till det erbjudandet.
🌐 Hobbyprojekt Del 1 av 3
📜 En mycket kort historisk tillbakablick
För numera drygt ett år sedan efter jag avslutat mitt examensarbete i den tvååriga distansutbildningen inom Webbutveckling med fokus på fullstack fast majoriteten av kurserna var mer backend snarare än frontend så hade jag fått försmak av "funktionell programmering" eller rättare sagt procedurbaserat paradigm snarare än objektorienterat (förkortat OO) paradigm.
Det är något mysigt med det procedurbaserade paradigmet där du mer tydligare kan se den data du arbetar med än att dölja alltid bakom (ärvda) klasser och objektinstanser där du inte alltid vet vad de innehåller oavsett hur mycket IDE-stöd du än får. Och när objekten i sig innehåller andra objekt och det hela är hårdtypat så blir krångligare för mig med så kallade "skill issues".
Kombinera sedan OO-paradigmet med inkorrekt bokstavsordning i det så kallade MVC-ramverket vilket egentligen borde vara CMV-ramverk eftersom du börjar med en rutt (eng. "Route") för att matcha mot någon unik resurs (eng. "URI") för att sedan antingen returnera resursen direkt (exempelvis en bild, ett ljudspår, ett videoklipp, eller kanske någon vanlig fil såsom JS, CSS, med mera) eller gå vidare till nästa steg i CMV.
Nästa steget är då naturligtvis data (eller "model") om du inte redan har returnerat något som ej behöver vidare behandling. Efter detta så kan du antingen returnera hämtad och/eller bearbetad data via JSON, XML eller annat önskvärt format eller så gå du vidare till det sista steget i CMV vilket då är "sidan" (eng. "page" eller "view").
Här kan du nu returnera en färdigkompilerad sida eller så kanske du måste kompilera någon som ej ännu har kompilerats. Nu har du genomgått alla steg i CMV-ramverket - eller vad jag kom att kalla för första versionen av numera FunkPHP - "RDP" eller "RouteDataPage". Det sistnämnda har så klart inte något som rullar på tungan precis.
Efter samtal med diverse LLM:er om bättre namn så ville jag först "FlowPHP" men det var redan upptaget och domänet var också upptaget. Så då när jag såg "Funk" så insåg jag också att "Funk" är en musikgenre såväl som förkortning av "Funktion" på svenska och när du säger det så kan det också låta som "func" eller engelskans "function" och jag är ju svensk så det hela blev perfekt på många nivåer och är ett slags "mentalt semantiskt påskägg" för icke-insatta att komma upptäcka på egen hand.
📜Version1️⃣: "RouteDataPage" (RDP)
Tar vi en titt då på första versionens mappstruktur så såg vi följande:
Mappar som skulle reflektera de viktiga stegen Route, Data & Page vars konfigurering skulle äga rum i dx_steps-mappen. Sistnämnda visade sig vara inte en så bra idé eftersom det blev lite bökigt att hålla koll på i vilken ordning saker och ting skedde/kördes i. På så vis bröt det mot det härliga med tydligt procedurbaserat paradigm.
(Psst! Ska vi vara tråkiga så går det att argumentera för att det mesta sker instruktion för instruktion med vissa undantag för flera instruktioner samtidigt beroende på processorarkitektur och så...)
Hursomhelst så blev det inte heller bättre när vi tittade på första versionen av indelningen av rutterna och deras prefixmotsvarande filer:
Vad som framgår i bilderna ovan är först och främst tre olika filer för tre olika saker: rutter, data och (eventuella) sidor. Tittar du på nedre bilden ovanför så ser du även hur mapparna data, pages och routes har sina egna filer för rutterna såväl som separata ruttfiler för själva middlewares för de slags rutterna! Snacka om mycket indelat för något som kunde ha varit så mycket bättre enhetligt!?🤔
Den nedre bilden från ovan visar dock en sak som är relativt nära nuvarande dagens version vilket är "routes_single_routes.php" (numera "routes.php") där varje rutt först är indelat på giltig HTTPS-metod (GET, POST, PUT & DELETE) och sedan på unika URI:er med stöd för dynamiska URI-segment tack vare kolon först efter varje snedstreck.
I och med denna första version med dessutom den jobbiga mappen dx_steps så blev det för mycket att göra för att bara få upp en enda simpel rutt till att börja med. Det var också faktumet att det behövde manuellt skrivas in i varje separata PHP-fil!!! (jösses!😱)
📜Version2️⃣: Förenklad RDP
Det hela förenklades nu genom att ta bort dx_steps-mappen och istället ha alla dessa steg i en och samma enstaka fil numera kallad "funkphp_start.php" och en och samma ruttfil kunde nu innehålla alla nödvändiga "RDP-delar" varje unika rutt inuti varje HTTPS-metod:
Bilden ovan är anpassad utifrån nuvarande filstruktur i vad som är numera den "slutgiltiga första versionen (version 3)". Med en rutt som kunde innehålla arraynycklar för vad som skulle köras och det spelade ingen roll hur du lade dessa arraynycklar för de kördes alltid i ordningen: middlewares -> handler -> data (om inte data redan returnerat) -> page.
Men allvarliga problem uppstod här:
Först och främst så betyder det att vid "GET/test" så körs alltså bara middlewares "auth" och "log". Men om Utvecklaren ville ha middlewares som körs innan redan på "/"-nivå då? Dessutom blev det också "påtvingat" att du måste nyttja arraynycklarna kallade "handler", "data", "page" fast du kanske inte ville det eller kanske ville kalla vissa för något annat? Var fanns friheten i det hela? Det hela höll på bli "ett ytterligare opinionsstarkt ramverk som påstås ha lösningen på allt!"🙃
Den huvudsakliga startfilen använde olika if-satser och höll sedan koll på och även den så kallade startfilen blev då i sin tur minst lika "påstridig" i hur och saker och ting borde köras vid varje inkommen HTTPS-förfrågan... Det var någonting här som inte riktigt fungerade som önskat och någonting drastiskt behövdes göras och det illa kvickt...!🤨
Trodde du att jag skulle skriva tre olika meningsbärande saker här likt diverse LLM:er gör? Nepp!
Hur skulle då dåvarande "förenklade RDP" förbättras/förenklas ytterligare för att maximera valfriheten för Utvecklaren samtidigt som vissa saker var opinionsstarka men ändå på ett sätt som gjorde det samtidigt relativt modulärt för hur Utvecklaren kunde välja att göra saker och ting på...?
Vad som behövdes var följande:
Möjligheten att välja själv vad som skulle köras i vilken ordning vid varje inkommen HTTPS-förfrågan.
Möjligheten att själv välja vilka arraynycklar som skulle användas för varje given rutt och även i vilken ordning de skulle köras.
Möjligheten att ha middlewares att samlas längs URI-segment så något som först låg på "/" kunde inkluderas och sedan köras innan något kördes på exempelvis "/test" eller till och med "/test/:id".
Möjligheten att kunna göra nästan hur som helst från start till slut samtidigt som en minimala "påstridighet" följdes med!
Till sist men inte minst: massor och då menar jag massor - av så kallade "medföljda batterier" för ingen gillar en ny batteridriven leksak utan medföljda batterier, eller hur?!😬
Nu blev det mycket att ta tag i!😮💨
(Fortsättning följer i nästa inlägg direkt efter detta!)
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Webbutvecklingsdagbok - efter studierna | Del 2 av 3
🌐 Hobbyprojekt Del 2 av 3
📜Version3️⃣: 🎷FunkPHP🐘
För att maximera möjligheterna för Utvecklaren samtidigt som det fanns en viss "påstridighet" i hur vissa saker och ting skulle göras så kom den enhetliga lösningen inspirerat från ordet "pipeline". Eller ta en titt på den nuvarande mappstrukturen vilket är vad som kommer att sjösättas i den första giltiga versionen av det 99 % funktionsbaserade hobby-PHP-ramverket:
Så här kan de olika yttre mapparna förklaras mycket kortfattat talat:
backups - Här - om så önskas - hamnar alla säkerhetskopior av filer när någon befintlig fil ändras så att innehåll försvinner eller om hela filen raderas exempelvis.
batteries - I denna kommer alla de så kallade "medföljda batterierna" att ligga vare sig det är olika middlewares för olika ändamål, eller "plugins" (inladdning av klassbibliotek för den som inte vill återuppfinna PHPMailer, PHPSpreadsheet, med mera på nytt i funktionell form!)
cli - Navigera in hit för att använda FunkCLI eller numera bara "funk" för vem orkar skriva "cli" hela tiden om du ändå redan är inne i mappen src/cli? Samma fil här anropas av REST API från gui-mappen tack vare Filesr-konfigurering i en .htaccess-fil i denna cli-mapp:
<Files "funk">SetHandler application/x-httpd-php</Files>
funkphp - Denna mapp läggs utanför public_html så att den hamnar på samma nivå eftersom denna inkluderas via index.php-startfilen i public_html dit alla HTTPS-förfrågningar skickas vidare om det inte är publika statiska filer inuti public_html som begärs som exempelvis public_html/css, public_html/js, public_html/fonts, public_html/images, public_html/osv.
gui - Tack vare framtida innehåll här så kommer det gå att göra fler saker visuellt och därmed svårare kunna göra fil direkt i filer för att snabbare "schavottera" så att säga!
public_html - Denna mapp ersätter den klassiska public_html-mappen (eller public enligt Laravel av någon outgrundlig anledning?!🙄) hos valfritt webbhotell som stödjer .htaccess-filer och PHP version 8.2 och uppåt.
schema - Här återfinns .sql-filer för att lägga till tabellerna i tables.php-filen så att relationer kan etableras så att inbyggd funktionalitet för högoptimerade SQL-förfrågningar och datahydrering kan äga rum såväl som valideringsgenerering.
template - En mystisk mapp vars namn egentligen är intetsägande på olika sätt och vis. Tanken är att valfria kodfiler läggs in här vilket sedan kan inkluderas vid "schavotterande" av olika slags filer. Exempelvis kanske du skapar en arraynyckel-fil till en viss rutt som du vill ska inkludera en viss "startkod" (tänk "code snippets") som automatiskt läggs in i början av den skapade arraynyckel-filens funktion.
test - Om Utvecklaren ändå anser att "100 % code coverage or it is all AI slop!" så finns mappen där tester kan läggas in och köras - under den lokala utvecklingen - med valfritt testbibliotek eller kanske till och med testramverk?! Jag har inte bevandrat mig inom testdriven utveckling så jag är för icke-insatt här!
Bli inte rädd nu när du ser denna PHP-array, men:
Vad du ser är "kärnan" i det hela för varje HTTPS-förfrågan. Jag hade en kortfattad diskussion om vad som skulle kallas för vad som körs efter alla funktioner (om de inte avbrutits innan via exit();!)
Jag var först inne på att kalla den för "exit" istället för "post-request" för jag tänkte på "exit" som i funktionen "exit" då jag lärde mig om "register_shutdown_function()" vilket låter dig köra en sista funktion efter att exit(); har anropats.
En sak du förmodligen reagerat på nu är, "Skämtar du...?! TRETTON separata pipeline-funktioner???" Här kommer vi då till det helt UNDERBARA med möjligheterna: Du kan - om du vill - bara lägga all logik du anser bör alltid köras oavsett i en och samma pl-fil ("pl" är förtkoningen av engelska ordet pipeline) och sedan så ser du bara en funktion som körs.
Hur du än väljer att göra så blir det en kompromiss på det ena eller andra viset! Och ja! Det finns dessutom en funktion som vilken funktion som helst kan anropa vilket då gör att när "post-request"vill köra sina pl-funktioner så skippas dem eftersom den först kollar om $c['req']['skip_post-request'] är sann medan standardvärde är falsk. MÖJ-LIG-HET & VAL-FRI-HET!!!🫡
function funk_skip_post_request(&$c)
{ $c['req']['skip_post-request'] = true;}
Om du granskat bilden ovan mer än vanligt så kanske du såg hur det finns pl-filer med "_v1" efter sig. Detta är för att tanken är att vid framtida versioner så kanske diverse medföljande pl-filer har uppdaterats men ändå kan återanvändas och detta gäller även för middlewares-filer då båda dessa "funktionsfiltyper" är tänkta att kunna återanvända emellan projekt som använder samma 99 % funktionsbaserade hobby-PHP-ramverk. Vad som troligen kommer skilja sig är de diverse funktionsfilerna inuti routes-mappen.
Just det... Vad hände med routes-mappen och dess routes.php-fil? Ta en titt själv:
Notera hur den har mapparna data och handler inuti sig medan mapparna sql och validation ligger utanför. De två inre mapparna har skapats via CLI-kommandona "php funk make:data test=>test" respektive "php funk make:handler v_test=>test".
Hade du däremot skrivit "php funk make:sql test=>test" eller "php funk make:validation v_test=>test" så hamnar filerna istället i de "påstridiga" mapparna sql respektive validation vilket alltid ligger i huvudmappen funkphp. Det icke-sagda resonemanget förrän nu är att dessa inte är tänkta att användas som arraynycklar för en given rutt!
Men JA! Du har helt rätt: på grund av hur VALFRITT det hela är så kan du hypotetiskt talat manuellt skapa mappen sql eller validation inti routes-mappen och sedan manuellt skapa funktionsfilerna och bara skriva in arraynycklarna manuellt för rutten:
'POST' =>
[
'/test' =>
[
'middlewares' => ["auth", "log"],
'sql' => ['silly' => 'oh_why']
'data' => ["test" => "test"],
'validation' => ['you' => 'do_this']
'handler' => ["test" => "test"],
'page' => 'test',
],
],
Däremot kommer funk make:sql eller funk make:validation alltid per standardbeteende att skapa funktionsfilerna i mapparna utanför routes men du stoppas inte från att manuellt göra det hela. Kan du gissa förresten vad denna pl-funktion gör?:
12 => 'pl_run_matched_route_keys',
Exakt! Den kör igenom ruttnycklarna för en given rutt i den ordning de framgår:
<?php return function (&$c) {
foreach ($c['req']['route_keys'] as $key => $_) {
if (!is_string($key)) {
$c['err']['PIPELINE']['REQUEST']['funk_run_matched_route_keys'][] = 'Route Key must be a String corresponding to the Folder where the Function File with corresponding Function Name would be inside of!';
return;
}
if (!isset($c['req']['route_keys'][$key])) {
$c['err']['PIPELINE']['REQUEST']['funk_run_matched_route_keys'][] = 'Route Key `' . $key . '` NOT found for the Route `' . ($c['req']['route'] ?? '<No Route Matched>') . '`. Please check your Route Keys in `funkphp/routes/routes.php` for the Route `' . ($c['req']['method'] ?? '<No HTTP(S) Method Matched>') . ($c['req']['route'] ?? '<No Route Matched>') . '`!';
return;
}
$matchKey = $c['req']['route_keys'][$key];
$keyFolder = $key;
$keyFile = '';
$keyFn = '';
if (is_string($matchKey)) {
$keyFile = $matchKey;
$keyFn = $matchKey;
} elseif (is_array($matchKey)) {
$keyFile = key($matchKey);
$keyFn = $matchKey[$keyFile] ?? '';
} else {
$c['err']['PIPELINE']['REQUEST']['funk_run_matched_route_keys'][] = 'Route Key `' . $key . '` must be a String or an Array with a Non-Empty String Value. No attempt to find a Route Key File was made!';
return;
}
if (isset($c['dispatchers'][$key][$keyFile])) {
if (is_callable($c['dispatchers'][$key][$keyFile])) {
$c['dispatchers'][$key][$keyFile]($c, $keyFn);
} else {
$c['err']['PIPELINE']['REQUEST']['funk_run_matched_route_keys'][] = 'Route Key `' . $key . '` File `' . $keyFile . '` is NOT a Callable Function. Please check your Route Key File in `funkphp/routes/routes.php` for the Route `' . ($c['req']['method'] ?? '<No HTTP(S) Method Matched>') . ($c['req']['route'] ?? '<No Route Matched>') . '`!';
return;
}
}
else {
$pathToInclude = ROOT_FOLDER . '/routes/' . $keyFolder . '/' . $keyFile . '.php';
if (!is_readable($pathToInclude)) {
$c['err']['PIPELINE']['REQUEST']['funk_run_matched_route_keys'][] = 'Route Key `' . $key . '` File `' . $keyFile . '` does NOT EXIST in `funkphp/routes/' . $keyFolder . '/` Directory! Please check your Route Key File in `funkphp/routes/routes.php` for the Route `' . ($c['req']['method'] ?? '<No HTTP(S) Method Matched>') . ($c['req']['route'] ?? '<No Route Matched>') . '`!';
return;
}
$c['dispatchers'][$key][$keyFile] = include_once $pathToInclude;
$c['dispatchers'][$key][$keyFile]($c, $keyFn);
}
}
};
funkphp/request/pl_run_matched_route_keys
Faktum är att den funktionen fungerar mer eller mindre lika som funktionen som kör pipeline-funktionerna:
function funk_run_pipeline_request(&$c)
{
if (
isset($c['<ENTRY>']['pipeline']['request'])
&& is_array($c['<ENTRY>']['pipeline']['request'])
&& count($c['<ENTRY>']['pipeline']['request']) > 0
) {
$count = count($c['<ENTRY>']['pipeline']['request']);
$c['req']['keep_running_pipeline'] = true;
for ($i = 0; $i < $count; $i++) {
if ($c['req']['keep_running_pipeline'] === false) {
break;
}
$fnToRun = "";
$pipeValue = null;
$current_pipe = $c['<ENTRY>']['pipeline']['request'][$i] ?? null;
if (
$current_pipe === null ||
(!is_string($current_pipe) && !is_array($current_pipe))
) {
unset($c['<ENTRY>']['pipeline']['request'][$i]);
$c['req']['number_of_deleted_pipeline']++;
$c['err']['PIPELINE']['REQUEST']['funk_run_pipeline_request'][] = 'Pipeline Request Function at index ' . $i . ' is either NULL or NOT a Valid Data Type. It must be a String or An Associative Array Key with a Value! (Value can be null, but that is probably not useful in most cases)';
continue;
}
elseif (is_array($current_pipe)) {
$fnToRun = key($current_pipe);
$pipeValue = $current_pipe[$fnToRun] ?? null;
$c['req']['current_passed_values']['pipeline']['request'][$fnToRun] = $current_pipe[$fnToRun] ?? null;
$c['req']['current_passed_value']['pipeline'] = $current_pipe[$fnToRun] ?? null;
} // "else" means it is a String so it has no value to store/pass on!
else {
$fnToRun = $current_pipe;
}
if (isset($c['dispatchers']['pipeline']['request'][$fnToRun])) {
if (is_callable($c['dispatchers']['pipeline']['request'][$fnToRun])) {
$runPipe = $c['dispatchers']['pipeline']['request'][$fnToRun];
$c['req']['current_pipeline_running'] = $current_pipe;
$c['req']['number_of_ran_pipeline']++;
$c['req']['next_pipeline_to_run'] = $c['<ENTRY>']['pipeline']['request'][$i + 1] ?? null;
$runPipe($c, $pipeValue);
}
} else {
$pipeDir = ROOT_FOLDER . '/pipeline/request/';
$pipeToRun = $pipeDir . $fnToRun . '.php';
if (file_exists($pipeToRun)) {
$runPipe = include_once $pipeToRun;
if (is_callable($runPipe)) {
$c['req']['current_pipeline_running'] = $current_pipe;
$c['req']['number_of_ran_pipeline']++;
$c['req']['next_pipeline_to_run'] = $c['<ENTRY>']['pipeline']['request'][$i + 1] ?? null;
$c['dispatchers']['pipeline']['request'][$fnToRun] = $runPipe;
$runPipe($c, $pipeValue);
} else {
$c['err']['PIPELINE']['REQUEST']['funk_run_pipeline_request'][] = 'Pipeline Request Function (`' . $fnToRun . '`) at index ' . $i . ' is NOT CALLABLE for some reason. Each Function File should be in the style of: `<?php return function (&$c) { ... };`';
$c['req']['current_pipeline_running'] = null;
}
} else {
$c['err']['PIPELINE']['REQUEST']['funk_run_pipeline_request'][] = 'Pipeline Request Function (`' . $fnToRun . '`) at index ' . $i . ' does NOT EXIST in `funkphp/pipeline/request/` Directory!';
$c['req']['current_pipeline_running'] = null;
}
}
$c['req']['deleted_pipeline']['request'][] = $current_pipe;
unset($c['<ENTRY>']['pipeline']['request'][$i]);
unset($c['req']['current_passed_value']['pipeline']);
$c['req']['number_of_deleted_pipeline']++;
}
$c['req']['current_pipeline_running'] = null;
if (
isset($c['<ENTRY>']['pipeline']['request'])
&& is_array($c['<ENTRY>']['pipeline']['request'])
&& count($c['<ENTRY>']['pipeline']['request']) === 0
) {
$c['<ENTRY>']['pipeline']['request'] = null;
}
$c['req']['keep_running_pipeline'] = false;
}
else {
$c['err']['MAYBE']['PIPELINE']['REQUEST']['funk_run_pipeline_request'][] = 'No Configured Pipeline Request Functions (`"<ENTRY>" => "pipeline"`) to run. Check the `[\'<ENTRY>\'][\'pipeline\']` Key in the Pipeline Configuration File `funkphp/pipeline/pipeline.php` File!';
}
}
funkphp/_internals/functions/r_route_funs.php - fr.om. rad 36
(Fortsättning följer i nästa inlägg direkt efter detta!)
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
Visa signatur
(V)ulnerabilities
(I)n
(B)asically
(E)verything
Programming
