abonnement Unibet Coolblue Bitvavo
  † In Memoriam † donderdag 21 april 2011 @ 09:28:28 #77
159966 lifeblind
pi_95794911
quote:
0s.gif Op donderdag 21 april 2011 08:18 schreef Intrepidity het volgende:

[..]

Graceful degradation. Styles moet je toewijzen met CSS, niet met PHP. Werkt het niet, dan maar met een javascript-achtige fallback. Sowieso voegen dat soort operaties nou niet bepaald extreem veel overhead toe, zeker niet als je jQuery uberhaupt al actief hebt.
Zeker op drukke websites is het niet verstandig dat soort duidelijke client-side operaties aan de server over te laten.
En op een site/pagina die zonder javascript moet werken waar je wel die stijlen wilt hebben? Nooit er van uit gaan dat iedereen javascript aan heeft staan. Sowieso dit soort dingen d.m.v. javascript toevoegen is een beetje overkill.

Nog een tipje m.b.t. dit, als je een template-engine zoals smarty gebruikt, kun je dit min of meer automatisch laten doen. Als je dan je data in je template zet, kun je gewoon aangeven welke class die om de x-aantal iterations moet doen, werkt veel simpeler. Op deze manier hou je ook logica van je code (data ophalen, er iets leuks mee doen etc.) gescheiden van je weergave (want dat doe je allemaal in je template).
pi_95800546
quote:
0s.gif Op donderdag 21 april 2011 09:24 schreef Pakspul het volgende:

[..]

idd, aangezien het maar één ifstatement is valt het echt reuze mee.
[ code verwijderd ]

En that's it :P
1
2
3
<?php
$className 
$i === 'classX' 'classY';
?>
;) nog korter...
pi_95801097
quote:
0s.gif Op donderdag 21 april 2011 09:28 schreef lifeblind het volgende:

[..]

En op een site/pagina die zonder javascript moet werken waar je wel die stijlen wilt hebben? Nooit er van uit gaan dat iedereen javascript aan heeft staan. Sowieso dit soort dingen d.m.v. javascript toevoegen is een beetje overkill.

Nog een tipje m.b.t. dit, als je een template-engine zoals smarty gebruikt, kun je dit min of meer automatisch laten doen. Als je dan je data in je template zet, kun je gewoon aangeven welke class die om de x-aantal iterations moet doen, werkt veel simpeler. Op deze manier hou je ook logica van je code (data ophalen, er iets leuks mee doen etc.) gescheiden van je weergave (want dat doe je allemaal in je template).
Ik ben van mening dat dit soort dingen een toevoeging zijn en dat graceful degradation hier dus op zijn plaats is. Mensen die JS uit hebben staan zijn er nauwelijks (en moeten tevens dood, want paranoide), en die zien dan geen zebra-striping in een tabel, big deal.
Gewoon nooit dat soort weergavezaken serverside laten afhandelen. Werkt leuk en snel, maar als je een paar miljoen hits per dag te verwerken krijgt en je hebt overal dat soort truucjes in je code zitten kunnen al die cycles al snel een hele server schelen. Niet dat ik verwacht dat je je daar direct mee bezig houdt, maar verkeerde dingen aanleren is nooit een goed plan.
  donderdag 21 april 2011 @ 12:35:05 #80
75592 GlowMouse
l'état, c'est moi
pi_95801142
quote:
2s.gif Op donderdag 21 april 2011 12:17 schreef mafkees01 het volgende:

[..]
[ code verwijderd ]

;) nog korter...
1
2
3
<?php
$className 
= ($i 2) ? 'classX' 'classY';
?>
;) nog korter...
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
  donderdag 21 april 2011 @ 12:39:46 #81
91039 mstx
2x1/2 = 1/2 x 1/2
pi_95801309
quote:
0s.gif Op donderdag 21 april 2011 12:35 schreef GlowMouse het volgende:

[..]
[ code verwijderd ]

;) nog korter...
Moet je alleen X en Y omdraaien. O-)
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
  † In Memoriam † donderdag 21 april 2011 @ 12:41:16 #82
159966 lifeblind
pi_95801368
quote:
0s.gif Op donderdag 21 april 2011 12:33 schreef Intrepidity het volgende:

[..]

Ik ben van mening dat dit soort dingen een toevoeging zijn en dat graceful degradation hier dus op zijn plaats is. Mensen die JS uit hebben staan zijn er nauwelijks (en moeten tevens dood, want paranoide), en die zien dan geen zebra-striping in een tabel, big deal.
Gewoon nooit dat soort weergavezaken serverside laten afhandelen. Werkt leuk en snel, maar als je een paar miljoen hits per dag te verwerken krijgt en je hebt overal dat soort truucjes in je code zitten kunnen al die cycles al snel een hele server schelen. Niet dat ik verwacht dat je je daar direct mee bezig houdt, maar verkeerde dingen aanleren is nooit een goed plan.
En dingen als drempelsvrij en dergelijke zeggen je niets? Sowieso, als je miljoenen hits per dag te verwerken krijgt moet je meer aan caching enzo denken, als je dan iedere keer de pagina's serverside opnieuw gaat opbouwen doe je sowieso al iets niet goed.
pi_95801586
quote:
0s.gif Op donderdag 21 april 2011 12:41 schreef lifeblind het volgende:

[..]

En dingen als drempelsvrij en dergelijke zeggen je niets? Sowieso, als je miljoenen hits per dag te verwerken krijgt moet je meer aan caching enzo denken, als je dan iedere keer de pagina's serverside opnieuw gaat opbouwen doe je sowieso al iets niet goed.
Zebrastriping op een braillemachine, goed idee! Ik snap je punt, maar ik zit in de B2B-hoek, en daar is dat eigenlijk geen prioriteit, maar vooruit.
Tuurlijk doe je aan caching, maar bij een site die inherent dynamisch is ben je toch continue je pagina's aan het verversen. Niet iedere hit, maar bij een website als facebook (ik noem maar een dwarsstraat) is het cachen van pagina's over het algemeen een vrij zinloze exercitie. Hooguit blokken.
Maar kom op, we hebben het hier over het kleuren van een paar rijen, is dat werkelijk iets waar je serverside technologie wilt inzetten? CSS-selectoren gebruiken, en als dat niet ondersteund wordt een regeltje javascript en klaar is kees. Het is niet alsof onder IE7 die hele website ineens onbruikbaar wordt van een regel javascript.
pi_95801592
quote:
0s.gif Op donderdag 21 april 2011 12:35 schreef GlowMouse het volgende:

[..]
[ code verwijderd ]

;) nog korter...
Zo zie je maar, waarom moeilijk doen in CSS als het zo prima kan :)
pi_95801604
quote:
2s.gif Op donderdag 21 april 2011 12:47 schreef mafkees01 het volgende:

[..]

Zo zie je maar, waarom moeilijk doen in CSS als het zo prima kan :)
Omdat CSS er voor bedoeld is, dat is waarom.
pi_95801794
quote:
2s.gif Op donderdag 21 april 2011 12:17 schreef mafkees01 het volgende:

[..]
[ code verwijderd ]

;) nog korter...
Het oog wil ook wat :P
pi_95802018
quote:
0s.gif Op donderdag 21 april 2011 12:47 schreef Intrepidity het volgende:

[..]

Omdat CSS er voor bedoeld is, dat is waarom.
Ach, als je er 10 regels code voor nodig hebt en 2 loops geef ik je gelijk, maar als de oplossing zo simpel is zie ik in waarom je het niet met PHP zou oplossen. Om nog maar niet te beginnen over het feit dat de CSS oplossing erg browser afhankelijk is...
pi_95802221
quote:
2s.gif Op donderdag 21 april 2011 12:58 schreef mafkees01 het volgende:

[..]

Ach, als je er 10 regels code voor nodig hebt en 2 loops geef ik je gelijk, maar als de oplossing zo simpel is zie ik in waarom je het niet met PHP zou oplossen. Om nog maar niet te beginnen over het feit dat de CSS oplossing erg browser afhankelijk is...
Misschien ben ik wel een ongelofelijk zeikende purist hoor, maar PHP is afaik een serverside-taal en dus niet bedoeld voor dergelijke weergavezaken. Ik gebruik PHP om semantisch juiste HTML uit te poepen (en overal lukraak css-klassen aanhangen valt daar imo niet onder), en hoe dat geïnterpreteerd wordt en uiteindelijk weergegeven wordt is het pakkie aan voor de clientside-talen zoals css en javascript.
Het zou wat wezen dat je je PHP script moet aanpassen om je website er anders uit te laten zien, dat hoort imho niet.
Daarnaast heeft het voorbeeld hierboven met de zebra striping natuurlijk nauwelijks toegevoegde waarde. Jammer dat IE gebruikers die eventueel niet zien bij zowel gebrek aan CSS3 als JS-ondersteuning, maar dat is zo'n kleine doelgroep dat mij dat niet relevant lijkt (en dan nog is alles gewoon functioneel en missen ze niks).
pi_95809800
ik heb wel een discussie opgang gebracht met mijn vraagje..
bedankt voor alle respons op de zebra-striping...mooi woord voor galgje, ga ik onthouden
pi_95993502
Weet iemand hoe ik dit moet gaan doen?

Ik heb tien input velden, zoals hieronder, deze moeten allemaal de database doorzoeken en aparte resultaten krijgen. Nu is het probleem dat alleen de eerste werkt (logisch).

1
2
3
<input type="text" name="Artikelnummer[1]">
<input type="text" name="Artikelnummer[2]">
<input type="text" name="Artikelnummer[3]">

PHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<?php
$sql
="SELECT Artikelnummer, Naam, Prijs FROM Producten WHERE Artikelnummer = '".$q."'" ;
$result mysql_query($sql)or die(mysql_error());
$rows mysql_num_rows($result);

If(
$rows == 0) {
echo 
"<td class='productnaam'>";
echo 
"Nummer niet gevonden";
echo 
"</td>";

echo 
"<td class='prijs'>";
echo 
"";
echo 
"</td>";

else 
{
$fetch mysql_fetch_assoc($result);
echo 
"<td class='productnaam'>";
echo 
$fetch['Naam'];
echo 
"</td>";

echo 
"<td class='Prijs'>";
echo 
"&euro; ";
echo 
$fetch['Prijs'];
echo 
"</td>";
}
?>

Hoe zorg ik ervoor dat het voor elke input apart word "verwerkt".
...
  dinsdag 26 april 2011 @ 14:03:51 #91
91039 mstx
2x1/2 = 1/2 x 1/2
pi_95993592
quote:
0s.gif Op dinsdag 26 april 2011 14:00 schreef afro het volgende:
Weet iemand hoe ik dit moet gaan doen?

Ik heb tien input velden, zoals hieronder, deze moeten allemaal de database doorzoeken en aparte resultaten krijgen. Nu is het probleem dat alleen de eerste werkt (logisch).
[ code verwijderd ]

PHP
[ code verwijderd ]

Hoe zorg ik ervoor dat het voor elke input apart word "verwerkt".
1
2
3
4
5
<?php
foreach ( $_POST['Artikelnummer'] as $k=>$v ) {
 
// hier de code die bij elk veld in de database gaat zoeken, $v is de waarde van het veld en $k de index
}
?>
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
pi_95995750
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<form method="post">
<textarea name="Artikelnummer[]"></textarea>
<textarea name="Artikelnummer[]"></textarea>
<input type="submit">
</form>
<?php
foreach($_POST['Artikelnummer'] as $Artikelnummer)
{
include 
'Jalalalala.php';
@
$sql="(SELECT Artikelnummer, Naam, Prijs FROM producten WHERE Artikelnummer =('$Artikelnummer'))";
$result mysql_query($sql)or die(mysql_error());
$rows mysql_num_rows($result);

If(
$rows == 0) {
echo 
"<td class='productnaam'>";
echo 
"Nummer niet gevonden";
echo 
"</td>";

echo 
"<td class='prijs'>";
echo 
"";
echo 
"</td>";

else 
{
$fetch mysql_fetch_assoc($result);
echo 
"<td class='productnaam'>";
echo 
$fetch['Naam'];
echo 
"</td>";

echo 
"<td class='Prijs'>";
echo 
"&euro; ";
echo 
$fetch['Prijs'];
echo 
"</td>";
}
     }
?>

Gelukt ^O^ Dank u!

[ Bericht 38% gewijzigd door afro op 26-04-2011 16:10:15 ]
...
pi_96002357
Ten eerste: zwaar onveilig de manier die je nu gebruikt..
Ten tweede: dit is nou precies een situatie waar prepared staments voor ontwikkeld is...
  dinsdag 26 april 2011 @ 17:45:50 #94
75592 GlowMouse
l'état, c'est moi
pi_96002495
Ten derde: wat een rare include
Ten vierde: een query binnen een loop is in dit geval erg onnodig
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_96012824
Hey GlowMouse, wat me opvalt, je zit altijd zo te muggenziften (no offense) op kleine foutjes/dingen die niet zo net zijn, maar ik zie je nooit beginnen over dat mensen de oude MySQL libs gebruiken en geen MySQLi.

Dit terwijl het (erg) ontmoedigd wordt om nog deze oude MySQL libraries te gebruiken, en volgens mij deze zelfs niet meer compatible zullen zijn met PHP6. Zou je daar niet eens op gaan hameren?

gr gr
Of toch du vader?
  dinsdag 26 april 2011 @ 21:07:07 #96
75592 GlowMouse
l'état, c'est moi
pi_96014148
Zolang je de extra features van MySQLi niet gebruikt, biedt MySQLi geen voordelen. Bovendien zie ik MySQL niet verdwijnen. Daarnaast moet je een database-class gebruiken, zodat mysql door mysqli vervangen nauwelijks tijd kost.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_96014918
Oracle ontmoedigt zelf de oude MySQL libs nog te gebruiken voor nieuwe projecten, en jij, als man van netheid en correctheid, zou daar toch waarde aan moeten hechten? :D
Of toch du vader?
pi_96015475
En inderdaad, na nader onderzoek bleek dat er 'sprake' was van het verwijderen van de klassieke MySQL libs in PHP6, maar dat ze daarvan hebben afgezien i.v.m. teveel actieve gebruikers ervan.

Maar goed, als je hier kijkt, zie je halverwege zo'n Comparison, waar MySQLi/PDO wordt aangeraden voor nieuwe projecten, en de oude MySQL libs niet.
Of toch du vader?
  woensdag 27 april 2011 @ 09:00:16 #99
25889 Sitethief
Fulltime Flapdrol
pi_96032819
Ten vijfde: leer te indenten
Stroek: Sitethief, die is heel groot en sterk :Y.
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht &gt;:)
  woensdag 27 april 2011 @ 09:11:57 #100
91039 mstx
2x1/2 = 1/2 x 1/2
pi_96033067
Ten zesde: onderdruk fouten niet met @ maar zorg dat je in eerste instantie geen fouten krijgt.
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
pi_96033257
quote:
0s.gif Op dinsdag 26 april 2011 21:07 schreef GlowMouse het volgende:
Zolang je de extra features van MySQLi niet gebruikt, biedt MySQLi geen voordelen. Bovendien zie ik MySQL niet verdwijnen. Daarnaast moet je een database-class gebruiken, zodat mysql door mysqli vervangen nauwelijks tijd kost.
Database-class als in: PDO. Eigen databasewrappers schrijven is tegenwoordig ook nergens meer voor nodig, daar hebben we PDO voor. Jammer alleen dat het een hoop hosters onvoldoende drivers aanbieden.
Als iedereen gewoon fijntjes leert met prepared statements te werken heb je in 1 klap de helft minder problemen in het kader van SQL-injectie en dergelijke.

quote:
14s.gif Op woensdag 27 april 2011 09:11 schreef mstx het volgende:
Ten zesde: onderdruk fouten niet met @ maar zorg dat je in eerste instantie geen fouten krijgt.
Ben ik in principe met je eens, maar er zijn uitzonderingsgevallen, zoals verschillen tussen de Linux en Windows-API's die errors veroorzaken, en andere randgevallen waarbij onderdrukking in plaats van rete-ingewikkelde foutafhandeling beter is. Maar inderdaad, bij in 99% van de gevallen is dat niet nodig. Samenvatting: onderdrukking voor tekortkomingen van PHP zelf is prima, maar voor fouten aan je eigen kant niet.

[ Bericht 10% gewijzigd door Intrepidity op 27-04-2011 09:26:11 ]
pi_96034706
quote:
0s.gif Op woensdag 27 april 2011 09:00 schreef Sitethief het volgende:
Ten vijfde: leer te indenten
Indenten?

quote:
14s.gif Op woensdag 27 april 2011 09:11 schreef mstx het volgende:
Ten zesde: onderdruk fouten niet met @ maar zorg dat je in eerste instantie geen fouten krijgt.
1
2
3
4
5
6
7
8
<?php
if (empty($_POST['Artikelnummer'])) {
    echo 
'';
}
else {    foreach(
$_POST['Artikelnummer'] as $Artikelnummer

{
?>

Zo goed opgelost?

1
2
3
<?php
$sql
=("SELECT Artikelnummer, Naam, Prijs FROM producten WHERE Artikelnummer =    '".mysql_real_escape_string($Artikelnummer)."'")
?>

En is dit veiliger?

[ Bericht 19% gewijzigd door afro op 27-04-2011 10:42:58 ]
...
  woensdag 27 april 2011 @ 10:28:35 #103
91039 mstx
2x1/2 = 1/2 x 1/2
pi_96034867
quote:
0s.gif Op woensdag 27 april 2011 10:22 schreef afro het volgende:

[..]

Indenten?

[..]
[ code verwijderd ]

Zo goed opgelost?
echo ''; is nogal nutteloos he. :P
1
2
3
4
5
6
<?php
if (!empty($_POST['Artikelnummer'])) {
  foreach(
$_POST['Artikelnummer'] as $Artikelnummer){
  }
}
?>
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
pi_96035109
quote:
0s.gif Op woensdag 27 april 2011 10:28 schreef mstx het volgende:

[..]

echo ''; is nogal nutteloos he. :P
[ code verwijderd ]

Dat is waar :D,
Bedankt!
...
pi_96035852
quote:
0s.gif Op woensdag 27 april 2011 10:22 schreef afro het volgende:

[..]

Indenten?

http://en.wikipedia.org/wiki/Indent_style
pi_96083272
Weet iemand hoe je multiple dimensional array output?
  donderdag 28 april 2011 @ 11:35:48 #107
136730 PiRANiA
All thinking men are atheists.
pi_96083329
quote:
99s.gif Op donderdag 28 april 2011 11:33 schreef -Datdus- het volgende:
Weet iemand hoe je multiple dimensional array output?
Hoe wil je hem outputten? Alleen even bekijken? var_dump($aMultiDimensional);
pi_96083690
Als je 'm daadwerkelijk netjes op het scherm wilt weergeven kun je denken aan geneste for-loops (alleen als je het aantal dimensies van tevoren weet), maar nog netter een recursieve methode (ook bruikbaar bij onbekend aantal dimensies)
pi_96083741
quote:
0s.gif Op donderdag 28 april 2011 11:35 schreef PiRANiA het volgende:

[..]

Hoe wil je hem outputten? Alleen even bekijken? var_dump($aMultiDimensional);
outputten! :)
pi_96118063
quote:
16s.gif Op donderdag 28 april 2011 11:47 schreef -Datdus- het volgende:

[..]

outputten! :)
Met print / echo dus...
pi_96125852
gebruik altijd print_r i.c.m. <pre> </pre>
  vrijdag 29 april 2011 @ 10:40:01 #112
4159 GI
Nee ik heet geen JOE
pi_96128430
quote:
0s.gif Op vrijdag 29 april 2011 09:16 schreef remi1986 het volgende:
gebruik altijd print_r i.c.m. <pre> </pre>
Same.
pi_96128747
quote:
0s.gif Op vrijdag 29 april 2011 09:16 schreef remi1986 het volgende:
gebruik altijd print_r i.c.m. <pre> </pre>
var_dump geeft mij ook iets teveel informatie terug, wel handig als het om type casting gaat dat je precies weet waar je mee werkt. Maar als je in een MVC framework werkt bouw je je models zo dat er een stuk type casting in zit, zodat je er vanuit kunt gaan dat de objecten waarmee je werkt ook daadwerkelijk het type hebben wat je verwacht i.p.v. dat losse type casting waar PHP mee werkt.
pi_96129723
quote:
0s.gif Op vrijdag 29 april 2011 10:48 schreef Pakspul het volgende:

[..]

var_dump geeft mij ook iets teveel informatie terug, wel handig als het om type casting gaat dat je precies weet waar je mee werkt. Maar als je in een MVC framework werkt bouw je je models zo dat er een stuk type casting in zit, zodat je er vanuit kunt gaan dat de objecten waarmee je werkt ook daadwerkelijk het type hebben wat je verwacht i.p.v. dat losse type casting waar PHP mee werkt.
Gelukkig zit type hinting voor scalar variables in de pijplijn voor een volgende PHP-versie ^O^
pi_96129793
quote:
0s.gif Op vrijdag 29 april 2011 11:11 schreef Intrepidity het volgende:

[..]

Gelukkig zit type hinting voor scalar variables in de pijplijn voor een volgende PHP-versie ^O^
Bron? Want ik ben echt zwaar benieuwd naar de uitwerking. Liefste zie ik zoiets als c# want dat verschil niet erg veel van PHP.

Mooiste zal zijn als string,integer,float etc ook classes zijn of structures zodat deze ook in functies worden geaccepteerd.
pi_96130634
quote:
0s.gif Op vrijdag 29 april 2011 11:13 schreef Pakspul het volgende:

Mooiste zal zijn als string,integer,float etc ook classes zijn of structures zodat deze ook in functies worden geaccepteerd.
Dat geeft vooral overhead, en zeker in een weakly typed taal als php heeft het andere nadelen. Zelfs in een taal als java zijn integers en floats etc gewoon primitives, die je eventueel wel in een Integer/Float etc class kan vatten. Maar dat riekt bij mij al snel naar overengineering. Niks mis met primitives. Misschien dat het voor strings handig kan zijn, bijv zoals het in javascript werkt bijvoorbeeld, waar een string een object en ook een pseudo array is. Voor de rest: keep it simple, stupid.
pi_96131034
quote:
0s.gif Op vrijdag 29 april 2011 11:13 schreef Pakspul het volgende:

[..]

Bron? Want ik ben echt zwaar benieuwd naar de uitwerking. Liefste zie ik zoiets als c# want dat verschil niet erg veel van PHP.

Mooiste zal zijn als string,integer,float etc ook classes zijn of structures zodat deze ook in functies worden geaccepteerd.
Zie o.a. http://sebastian-bergmann(...)s-in-PHP-5.3.99.html
Kortom kun je geen variabelen zoals "int $foo" declareren, maar wel types verplicht stellen in methodes, zoals nu ook al mogelijk is met arrays en objecten.
Scalar types worden hopelijk nooit classes. Heeft nauwelijks toegevoegde waarde en voegt inderdaad alleen maar overhead toe.
Wat ik wel erg jammer vind is dat de checking niet automatisch gebeurt. Je kunt wel methoden als "public function foo(int $parameter)" declareren, maar vervolgens moet je zélf met de reflection-API checken of die variabele wel van dat type is.
pi_96131672
Je moet PHP ook niet proberen te veranderen in wat het niet is en wat nooit de bedoeling was. Het is oorspronkelijk gemaakt als een zeer laagdrempelige, ubersimpele scriptingtaal. Als je er echt een stricte en volledige programmeertaal van wil maken inclusief type checking etc dan kun je beter met een schone lei beginnen, zodat je ook alle nare erfenissen uit de voorbije tijd kunt kwijtraken. Maar ja, dan kom je waarschijnlijk uit op iets zoals Python...
pi_96131918
quote:
0s.gif Op vrijdag 29 april 2011 11:53 schreef Farenji het volgende:
Je moet PHP ook niet proberen te veranderen in wat het niet is en wat nooit de bedoeling was. Het is oorspronkelijk gemaakt als een zeer laagdrempelige, ubersimpele scriptingtaal. Als je er echt een stricte en volledige programmeertaal van wil maken inclusief type checking etc dan kun je beter met een schone lei beginnen, zodat je ook alle nare erfenissen uit de voorbije tijd kunt kwijtraken. Maar ja, dan kom je waarschijnlijk uit op iets zoals Python...
Een ubersimpele scriptingtaal is het al jaren niet meer. Loosely typed is het inderdaad, maar dat is een bewuste keuze geweest. Een volledige taal is het al een heel poosje. Wat voor dingen mis jij zoal in de API dan? Dat het niet geleverd wordt met een compleet framework zoals bijvoorbeeld ASP.net dat doet klopt, maar dat zie ik als een groot voordeel, omdat ik dan zelf een framework kan kiezen.
Ben het met je eens dat PHP out-of-the-box niet klaar is voor enterprise toepassingen, maar juist het feit dat je zelf je componenten, opcode caching, frameworks en dergelijke kunt kiezen is een groot voordeel, iets wat ik bij ASP.net en dergelijke talen grotendeels mis.
Dit uiteraard afgezien van het feit dat je het kúnt gebruiken als een houtje-touwtje scripttaaltje, maar de mensen die dat doen kan ik uberhaupt niet serieus nemen.
Ik zeg niet dat PHP een stricte taal moet worden, maar als je type hinting wilt introduceren, doe het dan wel volledig en niet halfgebakken. Of maak automatische checking ten minste een configuratieoptie.
pi_96224726
Gebruikte eerst ook altijd print_r, maar tegenwoordig altijd var_dump omdat ik veel gebruik maak van arrays :) Vind die weergave altijd enorm duidelijk :)
  zondag 1 mei 2011 @ 21:55:45 #121
302853 themole
graaft totaal door.
pi_96224846
quote:
2s.gif Op zondag 1 mei 2011 21:53 schreef mafkees01 het volgende:
Gebruikte eerst ook altijd print_r, maar tegenwoordig altijd var_dump omdat ik veel gebruik maak van arrays :) Vind die weergave altijd enorm duidelijk :)
Idd qua weergave is var_dump wel de betere. :)
Niet altijd serieus
pi_96225378
quote:
14s.gif Op zondag 1 mei 2011 21:55 schreef themole het volgende:

[..]

Idd qua weergave is var_dump wel de betere. :)
Ligt er dan ook wel enorm aan.. Als ik een dynamische SQL query bouw dan vind ik een var_dump erg onhanding omdat er quotes omheen staan, welke type casting en de length. Dan is de eventuele fout in je query moeilijk te vinden..
Dan gebruik ik gewoon print weer.. Ligt er net aan wat ik wil debuggen :)
pi_96238281
Gebruik toch in godsnaam gewoon xdebug :') Af en toe wat gepruts om het te installeren maar ik beloof je dat je 10x sneller debugged dan met var_dump en dergelijke.
  maandag 2 mei 2011 @ 09:40:09 #124
4159 GI
Nee ik heet geen JOE
pi_96238473
quote:
0s.gif Op maandag 2 mei 2011 09:31 schreef Intrepidity het volgende:
Gebruik toch in godsnaam gewoon xdebug :') Af en toe wat gepruts om het te installeren maar ik beloof je dat je 10x sneller debugged dan met var_dump en dergelijke.
Waarom zou ik ? Ik heb een eigen db-debugger in mijn db-class ingebouwd en kom met print_r verder gewoon waar ik wil komen.
pi_96239400
quote:
3s.gif Op maandag 2 mei 2011 09:40 schreef GI het volgende:

[..]

Waarom zou ik ? Ik heb een eigen db-debugger in mijn db-class ingebouwd en kom met print_r verder gewoon waar ik wil komen.
En als je niet weet op welke code je programma crasht? Kun je ook fijn je methodes in stappen met print_r en dergelijke? Tuurlijk heb je het niet persee nodig, maar het scheelt een hele hoop tijd.
Dan zouden we met z'n allen net zo goed in notepad assemblycode kunnen gaan zitten tikken, maar dat doen we ook niet.
pi_96246814
quote:
0s.gif Op maandag 2 mei 2011 09:31 schreef Intrepidity het volgende:
Gebruik toch in godsnaam gewoon xdebug :') Af en toe wat gepruts om het te installeren maar ik beloof je dat je 10x sneller debugged dan met var_dump en dergelijke.
wtf is xdebug? Ik heb mijn code zo gemaakt dat als er iets mis gaat dat ik een exception krijg en met de stacktrace kan ik dan zien waar het fout gaat. Persoonlijk vind ik debug programma's ook brak. Zend heeft er ook 1 maar kan daar echt niet mee overweg aangezien ik mijn variabelen best diep heb zitten en dan ben ik met een print_r velen malen sneller.
pi_96249792
quote:
0s.gif Op maandag 2 mei 2011 13:43 schreef Pakspul het volgende:

[..]

wtf is xdebug? Ik heb mijn code zo gemaakt dat als er iets mis gaat dat ik een exception krijg en met de stacktrace kan ik dan zien waar het fout gaat. Persoonlijk vind ik debug programma's ook brak. Zend heeft er ook 1 maar kan daar echt niet mee overweg aangezien ik mijn variabelen best diep heb zitten en dan ben ik met een print_r velen malen sneller.
xdebug is een php-plugin die ook ondersteund wordt door de meeste IDE's waarbij je bij een exception of error meteen naar de betreffende regel springt in je IDE en waarna je alle variabelen en de loop van je programma kunt inspecteren. M.a.w. volledige debugging zoals je dat o.a. ook in visual studio .net hebt.
  zondag 8 mei 2011 @ 13:59:31 #128
113667 Keiichi
Konnichiwa!
pi_96503956
Ik ben op zoek naar een makkelijk middel op MySQL tabellen om te zetten in PHP classes zodat ik hier vrij makkelijk CRUD operaties mee kan doen, zonder dat ik een mysql query hoef in te voeren.

Ik heb wel het eea gevonden dat het van PHP classes naar MySQL tabellen gaat (Vrijwel alle MVC frameworks).

Rede waarom ik dit wil is dat mijn database gewoon als uitgangspunt genomen moet worden, die heb ik immers al ontworpen met alle bijhorende relaties tussen tabellen. Naast parent-child relaties, heb ik ook een relatie die bedoelt is voor inheritance. (Ik heb eigenlijk ook geen MVC framework gezien die dit als zodanig ondersteund)

Wie weet een toolkit die kan doen wat ik wil?
pi_96521269
Doctrine2 kan proxyklassen genereren uit een bestaande database, maar ik vermoed dat dit enigszins overkill is voor je.
  maandag 9 mei 2011 @ 07:49:53 #130
113667 Keiichi
Konnichiwa!
pi_96534852
Ik zie niet zo snel waar de overkill zou zitten, ik heb vanavond iets om me even goed in te verdiepen ;)
pi_96715743
Ik heb een vraagje betreft het automatisch wissen van data uit m'n tabel.
Ik run een server waarbij ik graag wil dat account's na bijvoorbeeld 30 dagen inactiviteit verwijderd worden. Nu weet ik dat je met behulp van een cronjob iets kan uitvoeren op een bepaald moment, tenminste voor zover ik heb gelezen. Maar in hoeverre kun je doormiddel van het checken van een datum in de tabel kijken of die 30 dagen niet actief is geweest.

Op dit moment bevat m'n tabel al een kolom waar elke keer de datum word aangepast als die inlogt.

Iemand die me kan helpen? :@
  donderdag 12 mei 2011 @ 20:54:29 #132
75592 GlowMouse
l'état, c'est moi
pi_96715790
Dat gaat met een WHERE in je query.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_96718354
quote:
0s.gif Op donderdag 12 mei 2011 20:54 schreef GlowMouse het volgende:
Dat gaat met een WHERE in je query.
Moet ik PHP dan bijvoorbeeld elke 24 uur de hele database checken en elk account met een datum van 30 dagen geleden laten verwijderen?

Dus ff letterlijk getypt: elke 24 > check DB > datum - 30 = DELETE

Ben nog geen prof in php/sql :)
  donderdag 12 mei 2011 @ 21:49:41 #134
75592 GlowMouse
l'état, c'est moi
pi_96721385
Precies, om de zoveel tijd met PHP een delete-query draaien.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_96724285
quote:
0s.gif Op donderdag 12 mei 2011 21:49 schreef GlowMouse het volgende:
Precies, om de zoveel tijd met PHP een delete-query draaien.
Het is soms echt te makkelijk, thanks :)
Ga even uitzoeken hoe ik een datum kan checken en er dagen vanaf halen ;)
pi_96727930
quote:
0s.gif Op donderdag 12 mei 2011 22:17 schreef dirkjo het volgende:

[..]

Het is soms echt te makkelijk, thanks :)
Ga even uitzoeken hoe ik een datum kan checken en er dagen vanaf halen ;)
Als je in de database datetime velden gebruikt, zou je eens kunnen kijken naar de mysql-functie datediff()
pi_96729465
quote:
0s.gif Op donderdag 12 mei 2011 22:54 schreef Light het volgende:

[..]

Als je in de database datetime velden gebruikt, zou je eens kunnen kijken naar de mysql-functie datediff()
Het zijn inderdaad datetime fields, zal eens even kijken. Thanks :)
pi_96729970
quote:
0s.gif Op donderdag 12 mei 2011 22:54 schreef Light het volgende:

[..]

Als je in de database datetime velden gebruikt, zou je eens kunnen kijken naar de mysql-functie datediff()
Even snel lopen kijken naar de datedriff() functie, maar als ik er zo naar kijk dan zou het ook moeten kunnen wanneer je gewoon gebruik maakt van de algemene varchar velden?
pi_96739034
Snel testje gedaan.

Als je dit doet

1SELECT `date_veld` FROM `tabel` WHERE DATEDIFF(`date_veld`, NOW()) < -30 

Krijg je data die ouder zijn dan 30 dagen. Wel verwarrend met < -30.

Dit kan je natuurlijk gebruiken met een DELETE WHERE query.
  vrijdag 13 mei 2011 @ 10:39:45 #140
75592 GlowMouse
l'état, c'est moi
pi_96740921
Als je varchar voor een datum gebruikt dan is het je eigen schuld.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_96742313
quote:
0s.gif Op vrijdag 13 mei 2011 10:39 schreef GlowMouse het volgende:
Als je varchar voor een datum gebruikt dan is het je eigen schuld.
Of van je voorganger waarmee je vanwege legacy-code maar moet zien te leven.
pi_96753867
quote:
0s.gif Op vrijdag 13 mei 2011 10:39 schreef GlowMouse het volgende:
Als je varchar voor een datum gebruikt dan is het je eigen schuld.
Doe ik niet, zijn gewoon datetime fields ;)
pi_96753915
quote:
0s.gif Op vrijdag 13 mei 2011 09:40 schreef remi1986 het volgende:
Snel testje gedaan.

Als je dit doet

[ code verwijderd ]

Krijg je data die ouder zijn dan 30 dagen. Wel verwarrend met < -30.

Dit kan je natuurlijk gebruiken met een DELETE WHERE query.
Dankje! Ga er vanavond/dit weekend eens even mee kloten :)
pi_96771092
Ik kom er niet uit, zal waarschijnlijk wel komen door m'n lage kennis van sql :@. Ik wou kijken wat het script van remi nou precies als result gaf dus flatste het volgende in elkaar:
1
2
3
4
5
<?php
    $result 
mysql_query("SELECT * FROM `ftpuser` WHERE DATEDIFF(`accessed`, NOW()) < -30");
    
$row mysql_fetch_array($result);
    echo (
$row['userid']);
?>

Dit geeft mij alleen het volgende als resultaat:
1 "gebruikersnaam"
(waarbij gebruikersnaam een waarde is die in 'userid' staat)

Wanneer ik dan bijvoorbeeld ga spelen met de waarde < -30 blijf ik constant dezelfde gebruikersnaam houden, terwijl ik zeer zeker weet dat er meerdere moeten verschijnen.

Iemand die mij uit de knoei kan helpen?

[ Bericht 2% gewijzigd door dirkjo op 13-05-2011 22:15:21 ]
pi_96771223
Kan iemand mij het volgende uitleggen, ik heb een tabel met 4 velden (expire_date [timestamp], user_id [int], action [varchar=50], value [text]) en wil deze tabel gebruiken om acties voor een bepaalde tijd in een database in te voeren. Echter werkt de volgende insert niet zoals verwacht

insert into `actions` (`expiredate`, `userID`, `action`, `value`)
VALUES (CUR_TIJD + $time,
$userID,
$action,
$value);

waar CUR_TIJD de huidige tijd (time()) + $time in seconden is. Wat doe ik fout?
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_96771603
$dirkjo: gebruik eens print_r :P ipv vardump :P

en DATEDIFF(`accessed`, NOW()) < -30 lijkt me leuker om dit te hebben

`accessed` >= DATE_SUB(CURDATE(),INTERVAL 30 DAYS)

zo pak je alles wat binnen 30 dagen valt ;) en wil je anders om dan doe je < :P
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  vrijdag 13 mei 2011 @ 22:25:30 #147
75592 GlowMouse
l'état, c'est moi
pi_96772237
quote:
0s.gif Op vrijdag 13 mei 2011 22:07 schreef dirkjo het volgende:
Wanneer ik dan bijvoorbeeld ga spelen met de waarde < -30 blijf ik constant dezelfde gebruikersnaam houden, terwijl ik zeer zeker weet dat er meerdere moeten verschijnen.
je echo't maar 1x, zie de voorbeelden op http://nl3.php.net/mysql_fetch_array
quote:
0s.gif Op vrijdag 13 mei 2011 22:09 schreef Chandler het volgende:
Kan iemand mij het volgende uitleggen, ik heb een tabel met 4 velden (expire_date [timestamp], user_id [int], action [varchar=50], value [text]) en wil deze tabel gebruiken om acties voor een bepaalde tijd in een database in te voeren. Echter werkt de volgende insert niet zoals verwacht

insert into `actions` (`expiredate`, `userID`, `action`, `value`)
VALUES (CUR_TIJD + $time,
$userID,
$action,
$value);

waar CUR_TIJD de huidige tijd (time()) + $time in seconden is. Wat doe ik fout?
Een timestamp veld vul je niet met een unix timestamp, en je wilt waarschijnlijk datetime gebruiken, zie http://dev.mysql.com/doc/refman/5.0/en/datetime.html
quote:
en DATEDIFF(`accessed`, NOW()) < -30 lijkt me leuker om dit te hebben

`accessed` >= DATE_SUB(CURDATE(),INTERVAL 30 DAYS)

zo pak je alles wat binnen 30 dagen valt ;) en wil je anders om dan doe je < :P
En dat is beter voor indices.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_96772523
Wist niet dat het beter was ;) maar leek mij meer logisch en begrijpelijk ;)

Ja ik wil het liefst werken met time() van php en timestamp maar zie dat datetime inderdaad een betere oplossing is, i'll try!
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_96773495
Raar :{ maar dit werkt dus niet

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
function()
{
        
$extime = (is_numeric($extime) && 
                   
$extime 0) ? time() + $extime 
                                
time() + 60;
        
        
$query $this->db->query("INSERT INTO `actions` (`expiredate`, `user_id`, `action`, `value`, `validate`)
                                   VALUES ('" 
date("Y-m-d H:i:s"$extime) . "',
                                           '" 
$this->db->escape($userID) . "',
                                           '" 
$this->db->escape($action) . "',
                                           '" 
$this->db->escape($value) . "',
                                           '" 
$this->db->escape($validate) . "')");
}
?>
waarbij $extime 60 is, dit zou dus 1 minuut extra moeten zijn maar dat is het dus niet?! en gewoon time() gaat ook niet werken :P wat doe ik nou fout? wil gewoon een datum in de toekomst in mijn tabel invoeren ;)
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_96773783
quote:
0s.gif Op vrijdag 13 mei 2011 22:25 schreef GlowMouse het volgende:

[..]

je echo't maar 1x, zie de voorbeelden op http://nl3.php.net/mysql_fetch_array

[..]

Een timestamp veld vul je niet met een unix timestamp, en je wilt waarschijnlijk datetime gebruiken, zie http://dev.mysql.com/doc/refman/5.0/en/datetime.html

[..]

En dat is beter voor indices.
Misschien erbij moeten vermelden dat ik 'printf' ook al heb geprobeerd.
  vrijdag 13 mei 2011 @ 22:50:34 #151
75592 GlowMouse
l'état, c'est moi
pi_96773877
quote:
0s.gif Op vrijdag 13 mei 2011 22:49 schreef dirkjo het volgende:

[..]

Misschien erbij moeten vermelden dat ik 'printf' ook al heb geprobeerd.
Nee, dat had niet gehoeven.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_96773960
Had ik gedaan maar resultaat was precies het zelfde :{ daarna veranderde ik de $extime = door het toevoegen van time() ?
The people who lost my respect will never get a capital letter for their name again.
Like trump...
abonnement Unibet Coolblue Bitvavo
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')