Voordat mensen een hartstilstand krijgen omdat ze mijn gebruikersnaam zien: er is geen echt probleem.
Ok, nu je weer op adem bent gekomen, ik heb een breadcrumb functie geschreven wat naar behoren functioneert alleen is de weergave nog niet 100%. Plaatscode: 142505
Ik unset een key omdat ik in de tweede parameter van de functie een tweede array() open, de unset zorgt er voor dat de weergave na het item waar de DB wordt verwerkt door gaat. Echter heb ik deze wel buiten de loop nodig voor een implode om de boel te scheiden in een string.
Iemand een suggestie hoe ik dit dien te verwerken ?
output:
Ik weet niet precies wat hier allemaal gebeurt, maar ik zie in ieder geval nog twee andere schoonheidsfoutjes .
De hyperlink tag "a" is geen self-closing tag (te meer omdat je ook altijd een </a> gebruikt). De forward slash aan het einde van de openingstag - <a ... /> - is dus nooit goed (regels 47 en 72).
Alles wat in het href-attribuut staat moet juist geformateerd worden:
- ampersands zouden ge-escaped moeten worden (& in plaats van &)
- alle URL-parameters (de waarden in ieder geval) zouden URL-encoded moeten zijn
Zodra je met de navigatie van een site bezig bent, bevindt je je in het middelpunt van een heleboel kruisende wegen.
Wat voor navigatie-methode je ook kiest, het lijkt mij dat alle interne links op een uniforme manier opgebouwd zouden moeten worden. Deze opbouw zou dus idealiter ook aangestuurd moeten worden door een centraal stuk functionaliteit, dus bijvoorbeeld in de vorm van een (link)functie. Dit heeft tevens tot voordeel dat, mocht je ooit besluiten om de navigatie (zij het op een backwards compatibele) manier om te gooien, je geen enkele regel code hoeft aan te passen behalve de implementatie van eerdergenoemde (link)functie. Op dit moment zou je in dat geval een groot deel van je breadcrumb-functionaliteit moeten herschrijven (en mogelijk ook de informatie in je database moeten herzien?).
Het volgende is waarschijnlijk ook niet wat je wilt horen, maar wanneer je nieuwe code schrijft, doe dit dan niet meer met de mysql_-functies maar gebruik MySQLi of PDO. De stap naar MySQLi vanuit het gebruik van mysql_-functies is echt niet groot. Leer dit jezelf aan nu het nog kan voordat je dit moet, want in PHP 7 bestaan de mysql_-functies niet meer.
Los daarvan is de originele MySQL-extensie (die je gebruikt wanneer je je bedient van de mysql_-functies) al meer dan ~10 jaar verouderd, zo lang loopt deze al niet meer in de pas met MySQL zelf en dus ook niet met innovaties en optimalisaties die in die tijd zijn doorgevoerd in de communicatie tussen PHP en MySQL.
1. Je doelt denk ik op <a href="" / ? denk ik want ik sluit de tag wel, dus ik zal de slash verwijderen.
2. ik zal de speciale chars wel even omzetten in codes. $sTeken is dat wel omdat ik dat karakter niet op me laptop (mac sinds kort) weet te vinden.
3. spatie = %20 ? Ik gebruik verder geen spaties of andere gekke karakters want ik stuur naar het pagina navigatie systeem dus: ?pagina=<array waarde>.
Kan ik zo maar overstappen naar MySQLI ? msqyli_erno, mysqli_result, mysqli_fetch_array en mysqli_query ?
EDIT: is de intentie en de output van de functie duidelijk ?
Kan ik zo maar overstappen naar MySQLI ? msqyli_erno, mysqli_result, mysqli_fetch_array en mysqli_query?
Die belofte kan ik je helaas niet geven, er is geen "technisch" bezwaar ofzo, als je dat bedoelt. De mysqli-functies zullen gewoon werken als je deze correct gebruikt. Hier zijn verder geen speciale vereisten voor die mogelijk niet voldoen.
Je zou dit natuurlijk ook gewoon eerst even kunnen testen he, voordat je alles omgooit en tot de conclusie komt dat "het niet werkt" . Maak een test script. Ook om de nieuwe vorm wat te oefenen. Is zeker geen verspilde moeite, op geen enkele manier.
Maar wederom is dit, eigenlijk net zoals het navigatie-verhaal, een kwestie van benadering.
Ik zal dit proberen te illustreren aan de hand van een voorbeeld.
De meest directe manier om alle functies om te zetten van mysql-_functies naar MySQLi (indien je de procedurele variant van MySQLi zou gebruiken, wat ook een aparte discussie waard is waarin je je kunt afvragen of dit verstandig is) is een search-and-replace in AL je code, en wellicht dat je hier en daar een extra parameter moet toevoegen. Dit zal doorgaans de connectie-resource, of liever gezegd, het connectie-object zijn.
Maar in plaats van mysql_whatever(a) gebruik je dan wellicht mysqli_whatever(b, a). Wederom heb je dan een "hardcoding" van het WAT (ik wil iets met een MySQL database doen) met het HOE (hiervoor gebruik ik mysqli_-functies of -methoden in plaats van mysql_-functies). In zekere zin bega je dan dezelfde fout. Wat nu als de manier van communicatie met je MySQL-database wéér verandert (hopelijk gaat dit niet snel gebeuren, maar toch). Dan kun je wéér een search-and-replace doen door heel je code heen.
Het is een beetje zoals het gezegde: Een ezel stoot zich in het algemeen...
Ik denk dat het handig is dat je wat defensiever leert programmeren. Je stevent nu altijd direct op je doel af, je programmeert letterlijk wat je wilt hebben. Dat is logisch (kijk even naar boven, Johan knikt instemmend). Maar niet altijd even handig.
Een wijziging of verandering van inzage -die niet ongewoon is tijdens groei, en als je veel programmeert is het normaal dat er een continue groei is (soms groeit de boel ook wat scheef )- heeft tot gevolg dat je alle, of een groot deel van je code opnieuw kunt schrijven, of je moet door heel je code ploegen om kleine wijzigingen door te voeren. Als je dat vaak of elke keer moet doen dan is dit een indicatie dat je je strategie mogelijk wat bij moet stellen.
Ook hier (communicatie met je database) is het handig en verstandig om het HOE en het WAT verder uit elkaar te trekken. Hierin zijn verschillende gradaties. Zo kun je héél ver gaan en alles zo abstract maken dat je alleen nog communiceert middels objecten zodat het niet eens duidelijk meer is dat je (specifiek) praat met een (MySQL) database. Dit levert een heleboel flexbiliteit op, maar ook een heleboel overhead.
Een eerste stap zou het schrijven van een wrapper zijn. Een wrapper is, letterlijk vertaald: snoeppapiertje, dat ding om je toffee. Vaak zijn wrappers object georienteerd opgezet, omdat dit nu eenmaal voordelen biedt boven een procedurele variant en daarnaast is de OOP richting een kant die steeds meer in bewogen wordt. Maar los daarvan, for the sake of this argument, een voorbeeld van een procedurele wrapper, al zou ik dit zo nooit aanpakken .
Stel dat je je mysql_-functies al had verpakt in wrappertjes:
Vervolgens gebruik je overal in je code myQuery(...) in plaats van mysql_query(...).
"Maar", zul je misschien ietwat denigrerend zeggen, "dit is slechts een alias, het voegt niets toe aan het origineel!". Dit is niet helemaal waar. Stel dat je meer van dit soort "aliassen" hebt (waar op den duur van zichzelf al wat toegevoegde waarde in zit) die je samen bundelt in een wrapper(class) / set van functies.
Komt daar het moment dat je moet overstappen van mysql_-functies naar bijvoorbeeld MySQLi. Dan hoef ik de implementatie van myQuery() en kornuiten enkel aan te passen naar:
(en een object georienteerde aanpak was een slimmer idee geweest)
Terwijl iemand anders misschien een dagtaak heeft aan het search-and-replacen van alle hardcoded instanties van mysql_-functies waarbij die persoon dus wederom dezelfde fout begaat. Plus je wijzigt dan ook effectief een HELEBOEL code, wat de kans op fouten vergroot. Als je echter maar op één plek code aanpast, hoef je deze ook maar op één plek te verbeteren.
Citaat:
EDIT: is de intentie en de output van de functie duidelijk ?
Ja, maar ik zou de aanpak wat veranderen. Ergens in breadcrumbnavigatie heb je allemaal moeilijke code zitten waarmee je data uit je database kunt trekken. Zoals ik het zie zijn er maar twee variabele elementen in de links:
- het TYPE link
- mogelijk extra argumenten, zoals een id
maar je hoeft dan niet direct (met nadruk op NIET DIRECT) uit te schrijven HOE het resultaat totstand komt, je kunt dit ook ergens anders afhandelen, bijvoorbeeld in een specifieke (callback)functie die je aanroept op grond van het type link, met als parameters de extra argumenten (getCategoryDataForBuildingMyBreadcrumbLinks($id))
Wanneer je alles meer in partjes opdeelt, kun je ook meer overzicht bewaren, immers, als je aan een partje werkt, hoe je niet meer precies te weten HOE alle andere partjes werken, maar enkel WAT ze (zouden ) moeten doen. Fouten worden dan meestal ook veel meer (direct) geïsoleerd, en het gebied waar een codewijziging invloed op heeft is ook vele malen kleiner... tenzij je ontwerp niet zo best was, in welk geval je beter eerst naar de tekentafel kunt terugkeren...
Ik vind erg lastig om iets te scripten (zeker de logica) om iets niet direct te gebruiken maar om later op te roepen en verwerken. Een aantal functies (maatwerk) vind ik zelf altijd wel handig.
Aangezien de omvang van het project waar ik mee bezig ben (je kan de lijn van de scripting door trekken aan de codes die je hier voorbij hebt zien komen). Elke pagina bevat minimaal 3 query's, 3 query-afhandeling etc etc evenals de $aError wordt op elke pagina direct afgehandeld en hier wil ik inderdaad vanaf. Niet zozeer omdat ik het erg vind om 5 regels code te kopieren, maar de pagina's worden ook zo lang (toch iets minder overzichtelijk debuggen).
Ik zie ook dat PHP de afgelopen jaren een stormachtige ontwikkeling heeft doorstaan op het gebied van OOP. Wat mij betreft kom ik daar later op terug, ik wil niet de huidige stijl hanteren en vervolgens een aantal classes schrijven en betrekken binnen de code (dan doe ik de OOP-voordelen enigsinds teniet ?).
Ik denk ook dat ik over een aantal maanden (als ik OOP beheer - en goed in kan zetten) enorm kan opluchten omdat het heel snel en efficient werken is natuurlijk (ik ben dus bereid om de investering aan te gaan wat het leren van OOP betreft). Echter moet ik reeel zijn en inzien dat ik deze voor mij onbekende technieken niet ga gebruiken (dan ben ik enorm beperkt) ik geniet nu ook wel van alle vrijheid(geen beperking) ondanks dat het niet op lange termijn ideaal is.
mysql -> mysqlI is inderdaad geen probleem.
Ik heb een redelijk beeld wat ik wel en wat ik niet kan, ik probeer gewoon zoveel mogelijk te leren en nieuwe technieken toe te passen). Daar was de opmerking MySQLI en tabellen een goed voorbeeld van, het feit dat ik nu veel meeneem voor in de toekomst koester en ik en daarom stel ik het OOP nog even uit.
Even voor in het heden: ik denk dat me blauwdruk redelijk goed is. Er komen echter wel een aantal functionaliteiten naarmate het project vordert ik denk dat dit vrij normaal is.
Daar is deze breadcrumb variant er 1 van. Ik denk dat dit een redelijke afzonderlijke functie is ingericht op het gebruik van mijn huidige project.
Broodkruimels: niet geldige parameter Query opbouw.<br />
Broodkruimels: niet geldige parameter Query opbouw.
Broodkruimels: niet geldige parameter Query opbouw.<br/>
Broodkruimels: niet geldige parameter Query opbouw.
Immers, je invoer -de $aURL parameter- bevat geen ['SELECT'] subarray.
Kan het zijn dat de code inmiddels veranderd is?
Zoja, gelieve een nieuwe versie op plaatscode.be te plaatsen anders is het voor ons onmogelijk om na te gaan wat er gebeurt.
Ik den dat de tweede variant ook scheef loopt omdat je on-the-fly (in de loop) $i ophoogt, en dan buiten de loop iets met $i gaat doen. Dit is nogal ongebruikelijk. Ondanks het feit dat $i daar nog beschikbaar is, is het onverstandig om daar dan $i te gebruiken, tenzij je precies weet wat je aan het doen bent. Als de loop van de volgende code is doorlopen:
<?php
for ($i=0; $i < 2; $i++) {
// doe dingen
}
?>
<?php
for($i=0;$i<2;$i++){
// doe dingen
}
?>
Dan is $i na afloop gelijk aan 2.
Zou je ajb na kunnen gaan of de code op plaatscode nog representatief is voor de bovenstaande input+output, want ik kan het eerste geval al niet reproduceren.
Ik include de SQL functies toch nergens, ik neem aan dat dit dan geen enkele invloed kan hebben op de code en zieker niet als ik het bestand rechtstreeks benader ? (hoop ik).
Thomas - 11/04/2016 15:00 (laatste wijziging 12/04/2016 14:15)
Moderator
Waarschijnlijk niet, maar je past je code aan naar een vorm die je enkel gebruikt voor debugging. Heb je de bug opgelost verander je deze weer terug naar hoe deze was. Maar je test dan in wezen niet de vorm die je code in de werkende variant heeft, dus in die zin is dat ook niet echt representatief voor de variant waarin je code zou moeten werken.
Als je een onderdeel van code aanpast (bijvoorbeeld omdat deze niet naar behoren werkt) is het verstandig om de overige factoren (tijdelijk) gelijk te houden, een beetje zoals bij (wetenschappelijk) onderzoek (ceteris paribus "de overige omstandigheden gelijk blijvend"). Anders gaan er mogelijk teveel dingen schuiven.
Het is misschien verleidelijk om te doen, en in dit geval heeft het mogelijk ook geen invloed, maar het is een (naar mijn mening) gewoon een slechte gewoonte .
----
EDIT: zou het kunnen zijn dat die » in de titel van je database-items zit? Een andere verklaring hebt ik niet, los van het feit dat sommige constructies nogal vreemd zijn zoals:
Die unset(); vindt ik ook gek, dit is eigenlijk gekomen door de output.
de tweede key in de eerste array (lees: array[1]) werd zowel als link geparst en ook nog is als tekst afgedrukt. Uit een print_r kon ik zien dat deze verwijderdt kon worden, eerst gewoon unset(array[key]) toen ging er een resultaat voor de link eruit, vandaar de + 1.
In de loop veranderd er niks maar het is vreemd (of ik snap het iig niet).
str_replace werkt bij mij goed. Staat er twee keer in (overbodig - tijdens het debuggen) maar het doet wat het moet doen.
Ik dacht heel dicht bij te zijn, op de output na dus. Toen ik inderdaad binnen deze functie mijn SQL(); functie betrok ben ik weer twee stappen terug. Dit weet ik want als ik de SQL (zelf geschreven functie) er buiten laat maar met mysqli_query(); werkt het wel weer. (ander probleem).
Er staan twee records in de databank waar ik een beroep op doe, geen van beiden bevat een bijzonder karakter.
Array([0]=> Beginpagina [1]=> Spijkerbroeken [2]=> titel [3]=> test )1
Met de unset wordt titel zoals ik graag wil eruit gehaald echter wordt het scheidingsteken wel geimplode en dus ook weergegeven gevolgd door een lege ruimte. Ik heb ipv een unset ook array_slice geprobeerd om de hele key te verwijderen, zonder succes.
EDIT: bovenstaande output gebaseerd op mijn laatst geplaatste code op plaatscode.be de output staat onder de functie. De link naar de categorie spijkerbroeken is correct opgebouwd.
PS; je was wel duidelijk met de self-closing tag mbt het a-atribuut. alleen zit het nog niet in me systeem.
Thomas - 13/04/2016 23:09 (laatste wijziging 13/04/2016 23:11)
Moderator
Indien ik jouw laatste fragment op plaatscode.be volg in combinatie met de eerder voorgestelde invoer kom ik niet tot bovenstaande uitvoer.
Het volgende ziet er in ieder geval niet fris uit:
Hoe komt een array daar terecht? Ik zie niet hoe dit kan met de eerder aangeleverde code.
Ofwel $aURL[$i]['PAGINA'] ofwel $aURL[$i] zou dan op enig moment een array moeten bevatten, wat zou betekenen dat je invoer niet goed is. Heb je ergens een typefout gemaakt in $aURL[<whatever>]['SELECT']? Is deze ergens ongelijk aan 'SELECT' (per ongeluk een spatie teveel?), dan wordt je link namelijk in de laatste vorm afgedrukt, waarmee die "Array" verklaard zou zijn.
Of je code is wéér veranderd.
Ik zie trouwens ook niet waarom je $aPaginas en $aURL in eerste instantie splitst.
Hm? Ik heb geen code uitgevoerd, enkel de iteraties met gegeven input handmatig nagelopen en nagespeeld wat de output dan (theorertisch) zou moeten zijn. Ik kwam dan alleen niet tot dezelfde output als jij had hierboven. Weet niet waarom dit verschilde maar als jij nu iets veranderd hebt waardoor het werkt, mij best.
Nah het werkt in ieder geval. Jammer dat ik de output dmv str_replace cosmetisch moet bijstellen maar ik ben blij. Bedankt.
EDIT: waarom ik niet 1 array gebruik als input; hier heb ik tijdens het schrijven van de functie niet overnagedacht. Het leek mij logisch als twee array's tegen elkaar "op boxen" om resultaten weg te strepen / vervangen.
Gesponsorde links
Je moet ingelogd zijn om een reactie te kunnen posten.
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
Gesponsorde links
.
)- heeft tot gevolg dat je alle, of een groot deel van je code opnieuw kunt schrijven, of je moet door heel je code ploegen om kleine wijzigingen door te voeren. Als je dat vaak of elke keer moet doen dan is dit een indicatie dat je je strategie mogelijk wat bij moet stellen.
Actiefste leden van de maand
