cms - fouten afvangen?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Informatieanalist - Oracle Softwareontwikkelaar

Enthousiaste en ervaren informatieanalist / softwareontwikkelaar gezocht!! Houdt jij van technische uitdagingen en krijg jij energie van het ontwerpen en realiseren van de beste software-oplossingen voor de dienstverlening? Dan is deze functie wellicht voor jou weggelegd! Het betreft een functie waarbij je, afhankelijk van het project samenwerkt met meerdere disciplines binnen ICT, vertegenwoordigers vanuit alle afdelingen in de organisatie, externe klanten en leveranciers. Je vertaalt de functionele vraag in technische oplossingen en realiseert deze. Afhankelijk van het type project of change geschiedt dit binnen de daarbij passende methodiek: Modern agile/scrum op basis van DevOps-gedachtengoed of traditioneel waterval. Wat zijn je

Bekijk vacature »

Pagina: 1 2 volgende »

Ozzie PHP

Ozzie PHP

27/01/2012 10:00:09
Quote Anchor link
Goedemorgen allemaal,

Ik vraag me af... ik ben bezig met een cms, en een onderdeel van de installatie is het invullen van een pad naar de juiste directory. Nu vraag ik me af ik op dit soort installatie-zaken een foutafhandeling moet toepassen.

Voorbeeld: de programmeur gaat het cms installeren en moet een pad instellen. Nu typt hij het pad verkeerd in. Moet er dan een nette foutmelding komen dat hij het pad verkeerd heeft ingevuld, of moet er een standaard PHP foutmelding in beeld komen?

Het mooiste is natuurlijk als er een fatsoenlijke foutmelding in beeld komt, maar dat houdt wel in dat je bij iedere pagina-aanroep moet controleren of het pad juist is ingevuld (meer concreet, of de ingevulde directory bestaat). Dit gaat ten koste van je performance.

Mijn vraag is hoe jullie hier mee omgaan. Vang je dit soort installatie-zaken wel of niet af?

Ander voorbeeld: de programmeur moet de locatie van een config.php bestand aangeven. Moet nu telkens (bij iedere pagina-aanroep) via catch en try gecheckt worden of de locatie klopt, of toon je gewoon de standaard PHP foutmelding?

Het tonen van een nette foutmelding is natuurlijk super gebruiksvriendelijk, maar het gaat (denk ik) wel iets ten koste van de performance.

Wat adviseren jullie?
 
PHP hulp

PHP hulp

21/10/2019 23:34:20
 
Joakim Broden

Joakim Broden

27/01/2012 10:24:54
Quote Anchor link
Zelf toon in nooit de PHP foutmeldingen, alle foutmeldingen worden in een log weggeschreven. Dus de gebruik zal nooit een PHP foutmelding te zien zijn. PARSE errors worden door gestuurd naar een apparte foutmeldings pagina.

Wat betreft de config/pad, waarom? Zorg dat de config altijd op 1 vaste plaatst staat. Die van mij is bv core/config.php, zo krijg je nooit foutmeldingen omdat je zeker weet dat daar het bestand staat.
 
Ozzie PHP

Ozzie PHP

27/01/2012 10:34:48
Quote Anchor link
Dankjewel voor je reactie. Het gaat mij vooral om de vraag of je de programmeur een nette foutmelding moet voorschotelen terwijl dit ten koste gaat van de performance? Of moet je zeggen: nou, die programmeur die moet maar kundig genoeg zijn en heeft geen nette foutmelding nodig.
 
- Ariën -
Beheerder

- Ariën -

27/01/2012 10:38:37
Quote Anchor link
Ik zou zo gebruikersvriendelijk mogelijk zijn, en een eigen foutmelding tonen als er iets ontbreekt waar systeembeheerder maar mee te maken kunnen hebben.

Denk aan ontbrekende config's...
 
Kees Schepers

kees Schepers

27/01/2012 10:39:02
Quote Anchor link
Ik denk niet dat het veel performance kost hoor. Je praat over native PHP checks. Als het een installatie script wat de markt op gaat (hetzij tegen vergoeding of open-source) zou ik het wel doen. Het moet dan out-of-the-box werken of in iedergeval goede feedback geven is mijn mening.
 
Ozzie PHP

Ozzie PHP

27/01/2012 10:46:01
Quote Anchor link
Oké thanks Kees en Aar, maar het betekent dan wel dat de miljoenen keren die de site wordt aangeroepen (ik denk even groot :)) die check wordt uitgevoerd. In feite is dit overbodig omdat het, eenmaal goed ingesteld, altijd zou moeten werken. Dus daar ligt een beetje mijn dubbele gevoel. Snappen jullie wat ik bedoel? In feite zit je dan continu checks uit te voeren die niet nodig zijn. Keerzijde is wel dat het voor de installateur / programmeur minder gebruiksvriendelijk is.

Wat nu?
 
- Jim  -

- Jim -

27/01/2012 10:51:32
Quote Anchor link
Ozzie,

ik denk dat je tijdens de installatie daar zorgvuldig op moet controleren, en een nette foutmelding moet geven als de directory/file niet bestaat/leesbaar/schrijfbaar is. De installatie gebeurd maar 1 keer, dus qua performance valt dat wel mee.

Als je dit pad opslaat in de config file, die bij iedere pagina wordt aangeroepen, zou ik hier dan geen intensieve controle meer laten plaatsvinden. Die controle heb je al gedaan tijdens de installatie. Noem het een soort van Design-by-contract. Tijdens run-time ondervind je dan geen performance issues.

Waar het mis kan gaan, is als iemand handmatig de config aanpast. Je zou ervoor kunnen kiezen om de config gecodeerd oid op te slaan en mbv een script de configuratie aan te passen. Dit script lijkt me erg belangrijk. Als dat goed werkt, ben je niet snel geneigd om handmatig in de config te wijzigen.
Gewijzigd op 27/01/2012 10:53:13 door - Jim -
 
Ozzie PHP

Ozzie PHP

27/01/2012 10:58:55
Quote Anchor link
"De installatie gebeurd maar 1 keer, dus qua performance valt dat wel mee."

Ja maar dit klopt dus juist niet.

Je moet je dus zoiets indenken:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
<?php
$config
= '/bla/bla/config.php';
if (file_exists($config)) {
 include $config;
}
else {
 echo 'Stomme programmeur, je hebt het pad fout ingevuld!';
}

?>


Die controle vindt nu bij iedere pagina-aanroep plaats. Dat is het probleem.
Gewijzigd op 27/01/2012 10:59:54 door Ozzie PHP
 
- Jim  -

- Jim -

27/01/2012 11:02:43
Quote Anchor link
Houd dit in dat je op iedere pagina verwijst naar de config-file? ('/bla/bla/config.php').
Dan heb je duplicaat-code, en zou ik dit op een enkele/centrale locatie zetten.
 
Kees Schepers

kees Schepers

27/01/2012 11:05:35
Quote Anchor link
He Ozzie,

Geloof me als je echt over high-traffic na gaat denken speelt dit nog niet eens een rol. Zelfs hier zijn we op dat niveau niet eens bezig en ik werk hier aan sites met miljoenen aan hits per maand. Voor high-performance moet je denken aan database round-trips, sessies, incorrecte for/foreach loops, oppassen met memory usage aan de hand van Arrays, etc.

if(file_exists().. blaat

kost echt denk ik maar 0.00000001 sec ofzo ;)
 
Ozzie PHP

Ozzie PHP

27/01/2012 11:19:49
Quote Anchor link
@Jim: nee, het gaat niet om duplicaat code, maar je moet toch iedere keer dat je een pagina opvraagt de congfigsettings includen. Dat is was ik bedoel.

@Kees: oké, thanks. Betekent dit dat jij wel dit soort controles inbouwt? Zo ja, doe je dat dan overal (bij iedere include)?
 
Kees Schepers

kees Schepers

27/01/2012 11:32:20
Quote Anchor link
Ik bouw overal controles in waar een eindgebruiker controle op heeft. Ik include sowieso niet veel meer omdat ik autoloaders gebruik maar bij een config zou ik het wel checken omdat die weggehaald zou kunnen zijn.
 
- Jim  -

- Jim -

27/01/2012 11:36:27
Quote Anchor link
Kees Schepers op 27/01/2012 11:05:35:
...
if(file_exists().. blaat

kost echt denk ik maar 0.00000001 sec ofzo ;)


Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?php
// Set the path to check
$path = "/tmp";
$amountOfChecks = 1000000;

// Set the start-time
$start = time();

// Check 1000000 time for path-existance
for($i=0; $i <= $amountOfChecks ; $i++)
{

    // Check
    file_exists($path);
}


// Show the duration
$duration = (time() - $start);
echo "Duration: " . $duration . PHP_EOL;
echo "Duration per check: " . ($duration / $amountOfChecks) . PHP_EOL;
?>


Als je per request 1x de settings-file include, is dat geen probleem.
Uit het code voorbeeld hierboven kan je ook zien dat het bij 1.000.000 checks nog geen probleem is.

Als blijf ik van mening dat als de controle 1x intensief is gedaan, is het niet nodig/overbodig om het te blijven controleren. Als je toch de focus hebt op performance, reduceer overbodige controles.
 
Ozzie PHP

Ozzie PHP

27/01/2012 11:40:28
Quote Anchor link
@Kees: De eindgebruiker heeft er geen controle op, maar de programmeur wel. Hij moet het pad in het bestand aanpassen. Zie jij een programmeur als eindgebruiker dan?

@Jim: kun je voor de volledigheid even de resultaten vermelden?

"Als blijf ik van mening dat als de controle 1x intensief is gedaan, is het niet nodig/overbodig om het te blijven controleren. Als je toch de focus hebt op performance, reduceer overbodige controles."

Hier valt iets voor te zeggen, maar in mijn voorbeeld is dat toch niet te realiseren?
 
- Jim  -

- Jim -

27/01/2012 12:12:35
Quote Anchor link
Ozzie PHP op 27/01/2012 11:40:28:
...
@Jim: kun je voor de volledigheid even de resultaten vermelden?

A: Dat verschil per server. Heb het script gepost zodat je kunt testen.
Quote:
"Als blijf ik van mening dat als de controle 1x intensief is gedaan, is het niet nodig/overbodig om het te blijven controleren. Als je toch de focus hebt op performance, reduceer overbodige controles."

Hier valt iets voor te zeggen, maar in mijn voorbeeld is dat toch niet te realiseren?


Als je de include('path/to/config') 1x gebruikt in je index pagina, kan je het 1x controleren. Maar het is afhankelijk hoe je de omgeving opgebouwd hebt.
Worden alle pagina's apart aangesproken? of worden alle pagina's via de index-pagina aangesproken?
In het eerste geval, moet je de controle op iedere pagina uitvoeren. (Veel duplicaat code). In het 2e geval, staat de code 1x (bij voorkeur op een centrale plek), wordt vaak aangesproken, maar heeft weinig impact op de performance.
 
Ozzie PHP

Ozzie PHP

27/01/2012 14:16:43
Quote Anchor link
Ah dat bedoel je... ik gebruik de code inderdaad 1 keer... maar dan nog steeds wordt de controle dus bij iedere pagina aanroep (het opvragen van een pagina in de browser) uitgevoerd. Dus iedere keer als je op een knop / link op de website klikt dan wordt de controle uitgevoerd.
 
Wouter J

Wouter J

27/01/2012 15:20:56
Quote Anchor link
@Jim, voor tijd testen moet je microtime (met parameter true) gebruiken. Niet time.

Ik heb weer een testje geschreven, zie het resultaat hier: http://waldio.webatu.com/phpbench/file-check.php
Broncode geef ik maar niet vrij, want ik heb nog nooit zo'n lelijke en slordige code geschreven...
 
Ozzie PHP

Ozzie PHP

27/01/2012 15:25:24
Quote Anchor link
Thanks Wouter... hoeveel is 42µs eigenlijk? :-s
 
Jurgen B

Jurgen B

27/01/2012 15:52:44
Quote Anchor link
1 seconde = 1.000 milliseconden = 1.000.000 micro(µ)seconden
Gewijzigd op 27/01/2012 15:52:55 door Jurgen B
 
Ozzie PHP

Ozzie PHP

27/01/2012 16:11:22
Quote Anchor link
Dus 42µs = 0,000042 seconde?
 
Jacco Brandt

Jacco Brandt

27/01/2012 16:12:18
Quote Anchor link
Ja.
 

Pagina: 1 2 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.