Archief - PHP/JS: Alert laten verschijnen

Biebel · 23 dec 2005

sSkoEziE zei:
...

Ah juist ja, was dat alweer vergeten

B.

BertG · 23 dec 2005

euh, jah... zijn hier wat mensen die (sorry van de expressie) uit hun nek klappen...

echo versus print (==> is wordt)

Code:

print           ==> echo "\n";
print "demo", 5 ==> echo "demo", " ", 5, "\n";
echo "demo", 5  ==> echo "demo", 5;

ook dat html blokken omgezet worde naar echo of print statements is niet correct

http://www.php.net/manual/en/tutorial.useful.php zei:
Instead of using a PHP echo statement to output something, we jumped out of PHP mode and just sent straight HTML.

http://www.php.net/manual/en/tutorial.useful.php zei:
When PHP parses a file, it looks for opening and closing tags, which tell PHP to start and stop interpreting the code between them. Parsing in this manner allows php to be embedded in all sorts of different documents, as everything outside of a pair of opening and closing tags is ignored by the PHP parser.

Zoals je kan zien wordt de html code direct doorgestuurd.

Hoop dat dit duidelijk is.

trouwens... tip (gevonden toen ik zocht naar bewijzen voor mijn stellingen)
Voor mensen die vaak html en php mixen...

Code:

<?= expression ?> zelfde als <? echo expression ?>

killgore · 23 dec 2005

BART_SIMPSON416 zei:
Nou, ik weet niet sinds waneer jij met php bezig bent maar op oudere apache servers met php3 gebeurde dit dus wel :|

1) Ik weet vrij goed wanneer gij met uw achterlijke vragen en opmerkingen hier gestart zijt en dan was de 5 beta al uit, gij waart dus niet bij de 3 betrokken, ik heb zelf amper het einde van php3 als std meegemaakt :ironic:.

2) Wat jij zegt zou me sterk verbazen en is volgens mij gewoon een php-fabeltje. Het is gewoon vrij onmogelijk. Apache gaat nl. zelf niets interpreteren van html, dus em kan ook geen <?Php ?> tags tegenkomen om naar php te sturen. wat apache doet bij een "gewoon" html document is ten hoogste eruithalen welk type het is en dan terugsturen naar de gebruiker, want html wordt (zoals je met je geniale invallen wel weet) USER-side geparset. Het hele document wordt dus op <?php tags gecheckt binnen php zelf, en dus zal je steeds maar 1 instantie van php starten. Het kan zijn dat starten en afsluiten trager ging in php3, maar die reden die jij opgeeft betwijfel ik toch zeeeeeeer sterk. Ik heb zelf al enkele apache & iis modules geschreven (die dus een bepaalde extensie parsen) en ik zou niet weten hoe ik apache moet zeggen: "dat moet ik parsen, de rest moet ek nie hebben"

.

3) @djeez: die interne echo buiten <?php ?> is echter wel wat sneller omdat ze vrij rechtstreeks wordt toegevoegd aan de ob & niet eerst als functie moet worden geïnterpreteerd (dit is echter muggenziften

).

4) Het gebruik van ' en ": gebruik gewoon altijd expliciete concatenatie: gebruik dus . en zet nooit variabelen binnen uw ' of ", dan zijn ze even snel (hebben ze ook optimale snelheid trouwens) en is uw code duidelijker.

5) Het beste voor output is en blijft de template om onder andere volgende redenen:

Duidelijke scheiding van code & layout (je kan hele code zo "lezen" en layout kan gepreviewed worden zonder problemen ).
Zeer makkelijke samenwerking tussen coder & designer -> In een groot project kan er tot de testfase bijna 100% onafhankelijk gewerkt worden. Het enige wat de coder moet weten is welke variabele-namen de designer gebruikt en de designer moet een kleine code-syntax bijleren voor de template!
Je kan zeer simpel aan caching werken zonder rare ob_start structuren te gebruiken
Je code wordt uitgevoerd VOOR elke vorm van output (tenzij er bv. processing tekst moet worden weergegeven). Dit vermijdt de gebruikelijke header problemen.
Je kan zeer makkelijk aan foutrapportering gaan doen via templates. Geen lelijke blank bg errors meer . In combinatie met goede fout-catchers (hiermee verwijs ik NIET naar try-catch wat brak is imho) kan je een nagenoeg perfect gebruiksvriendelijk fout-systeem opbouwen .
...

my 0.02€ over php & output

.

Biebel · 23 dec 2005

killgore zei:
4) Het gebruik van ' en ": gebruik gewoon altijd expliciete concatenatie: gebruik dus . en zet nooit variabelen binnen uw ' of ", dan zijn ze even snel (hebben ze ook optimale snelheid trouwens) en is uw code duidelijker.

Ok, op dat vlak is er dus niks verandert. Zo deed ik het zelf altijd

killgore zei:
5) Het beste voor output is en blijft de template om onder andere volgende redenen:
...

Je kan zeer makkelijk aan foutrapportering gaan doen via templates. Geen lelijke blank bg errors meer . In combinatie met goede fout-catchers (hiermee verwijs ik NIET naar try-catch wat brak is imho) kan je een nagenoeg perfect gebruiksvriendelijk fout-systeem opbouwen .

...

Templates zijn idd de beste oplossing voor grote projecten die design intensief zijn en waar je met een 'team' aan werkt.
Maar wat het foutsysteem betreft ben ik niet echt voorstander om de eindgebruiker de 'echte' fout te laten zien. Je hebt namelijk verschillende soorten fouten:
* Datafout: die interpreteer je tijdens het uitvoeren van de code (Application logic) en gooi je binnen de template zelf via een goed geformuleerde boodschap. Het is vrij eenvoudig om de standaard error functies van php te gebruiken en dan een custom error reporting function inbouwen om iets terug te geven naar de gebruiker
* Kritieke fout: hier is de aard van de fout nuttig voor de coder maar niet voor de eindgebruiker. Dan volstaat het om een standaard error handler template met de nodige informatie te tonen en 'onderhuids' een mail of zo te verzenden naar de coder met alle info omtrent de fout.

Dus het gebruik van templates voor error handling heeft voor mij niet direkt een meerwaarde. Het afhandelen van fouten gebeurt meestal op het niveau waar uw core de templates aanroept, niet in de template zelf. Alleja, das toch hoe ik erover denk

Maar voor de rest overschot van gelijk

B.

dJeez · 23 dec 2005

BART_SIMPSON416 zei:
Nou, ik weet niet sinds waneer jij met php bezig bent maar op oudere apache servers met php3 gebeurde dit dus wel :|

PHP3 maakte wel degelijk een onderscheid tussen " en ', stop dus misschien eens met dergelijke onzin te verkopen.

killgore · 23 dec 2005

Biebel zei:
Ok, op dat vlak is er dus niks verandert. Zo deed ik het zelf altijd

Templates zijn idd de beste oplossing voor grote projecten die design intensief zijn en waar je met een 'team' aan werkt.
Maar wat het foutsysteem betreft ben ik niet echt voorstander om de eindgebruiker de 'echte' fout te laten zien. Je hebt namelijk verschillende soorten fouten:
* Datafout: die interpreteer je tijdens het uitvoeren van de code (Application logic) en gooi je binnen de template zelf via een goed geformuleerde boodschap. Het is vrij eenvoudig om de standaard error functies van php te gebruiken en dan een custom error reporting function inbouwen om iets terug te geven naar de gebruiker
* Kritieke fout: hier is de aard van de fout nuttig voor de coder maar niet voor de eindgebruiker. Dan volstaat het om een standaard error handler template met de nodige informatie te tonen en 'onderhuids' een mail of zo te verzenden naar de coder met alle info omtrent de fout.

Dus het gebruik van templates voor error handling heeft voor mij niet direkt een meerwaarde. Het afhandelen van fouten gebeurt meestal op het niveau waar uw core de templates aanroept, niet in de template zelf. Alleja, das toch hoe ik erover denk

Maar voor de rest overschot van gelijk

B.

Kdenk da ge mij nie goe begrijpt op foutafhandeling ze

. Wat gij zegt bedoel ik juist, je kan zelf de fouten mooi weergeven, ik heb nergens gezegd dat je ze MOET weergeven & exact in hetzelfde formaat moet weergeven als php ze aan u geeft (zou wat wegnemen he van uw schoon output

.
Met foutafhandelers bedoelde ik ook dat je bv. je fout in een db opslaat zodat een admin ze later kan gaan bekijken en je gebruiker bv. gewoon laat weten dat er EEN fout is opgetreden (of indien niets ernstig gewoon niets laat weten)

.

Biebel · 23 dec 2005

Ah k, ik snapte het nie goe wat je wou aantonen met het nut van templates en error handling

B.

Archief - PHP/JS: Alert laten verschijnen

Biebel

Legacy Member

BertG

Legacy Member

killgore

Legacy Member

Biebel

Legacy Member

dJeez

Legacy Member

killgore

Legacy Member

Biebel

Legacy Member