---

Jeg er efterhånden ved at få lavet nogle klasser, som jeg genbruger på
tværs af systemer. Fx har jeg en databaseklasse og en mail-klasse, som
jeg har lagt i følgende biblioteksstruktur:

/core/

Så har jeg lavet et modul, som udnytter både databaseklassen og
mail-klassen, nemlig et nyhedsbrevsmodul, og det er placeret i.

/newsletter/

Nu er det sådan at e-mails skal sendes med den interne mail-funktion,
hvis systemet ikke har specificeret en SMTP-server. Der er altså i
mail-klassen en if-else-forgrening.

Specifikationen af smtp-serveren kan naturligvis skrive som et parameter
til funktionen, men det er måske lidt uhandy, da en hjemmeside ofte skal
sende e-mails fra flere sider, og man så bliver nødt til at specificere
smtp-serveren hver gang klassen skal bruges? Det er heller ikke smart at
skrive den ind i selve klassen, for så skal vi til at rette i klassen,
hvis smtp-serveren skifter. Den samme problematik gælder for databasen,
hvor man ofte kun bruger en database.

Hvor skal jeg definere disse konstanter - er der nogen der har
erfaringer for det? Er det smart at lave et bibliotek, som hedder
/config/ - og hvad skal filerne så hedde. Det betyder jo også at disse
indstillinger skal inkluderes på hver side, hvor de skal gøre sig nyttige?

Spørgsmålet er altså, hvor det kan være smart at have sine indstillinger?

/lars


--
Lars
www.fodboldenslegestue.dk   www.larsolesen.dk
www.discimport.dk      www.vih.dk

---

[snip]

jeg ville lave en default i klassen (typisk localhost), og så ville jeg
lave en public funktion i klassen som kunne sætte hosten.

$myclass->SetHost("newhost");

med dette, så er det lidt ligegyldigt hvor du smider dine configs, for
du kan bare kode ind at den skal sætte host lige inden den sender
mailen.

---

Lars Olesen wrote:
> Specifikationen af smtp-serveren kan naturligvis skrive som et parameter
> til funktionen, men det er måske lidt uhandy, da en hjemmeside ofte skal
> sende e-mails fra flere sider, og man så bliver nødt til at specificere
> smtp-serveren hver gang klassen skal bruges? Det er heller ikke smart at
> skrive den ind i selve klassen, for så skal vi til at rette i klassen,
> hvis smtp-serveren skifter. Den samme problematik gælder for databasen,
> hvor man ofte kun bruger en database.
>
> Hvor skal jeg definere disse konstanter - er der nogen der har
> erfaringer for det? Er det smart at lave et bibliotek, som hedder
> /config/ - og hvad skal filerne så hedde. Det betyder jo også at disse
> indstillinger skal inkluderes på hver side, hvor de skal gøre sig nyttige?
>
> Spørgsmålet er altså, hvor det kan være smart at have sine indstillinger?

I config filer...
Nu kender jeg ikke selve systemet dybere - skal den sende e-mail gennem
flere forskellige SMTP servere på samme server - eller er der altid kun
en SMTP server eller localhost smtp'en (mail funktionen)?

Spørgsmålet er snarere hvorvidt include/config filen skal ligge i selve
applikationen eller i klassen eller begge dele.

En mulighed kunne være at en configfil i hver... f.eks. en config til
klassen som så således ud:
<?php
if(!isset($useSMTP)) {
$useSMTP = true;
}
if($useSMTP && !defined("SMTP_SERVER")) {
define("SMTP_SERVER", "smtp.example.com");
}
?>

Så har du mulighed for at gøre følgende ting...

1. Send med intern mail.
<?php
$useSMTP = false;
require("mailclass.php"); //inkluderer selv config filen
?>

2. Send med lokal defineret SMTP
<?php
define("SMTP_SERVER", "smtp.foo.bar");
require("mailclass.php");
?>

3. Send med global defineret SMTP
<?php
require("mailclass.php");
?>


En anden mulighed kunne være at smide $useSMTP som en ekstra parameter -
som eventuelt var sat default til false i selve funktionen :)


Bare lige mit input - håbede du kunne bruge det til noget ;)

mvh
Johan

---

Johan Holst Nielsen wrote:
> I config filer...
> Nu kender jeg ikke selve systemet dybere - skal den sende e-mail gennem
> flere forskellige SMTP servere på samme server - eller er der altid kun
> en SMTP server eller localhost smtp'en (mail funktionen)?

Der vil oftest kun være en smtp-server på samme server.

> Spørgsmålet er snarere hvorvidt include/config filen skal ligge i selve
> applikationen eller i klassen eller begge dele.

Ja, det tror jeg du har ret i!

>[snip]

Det er en smart løsning. Det tror jeg, at jeg vil arbejde videre med.

> Bare lige mit input - håbede du kunne bruge det til noget ;)

Det kan jeg i hvert fald. Dit forslag er egentlig at bruge define() og
lave en global indstilling i applikationen, og hvis man får brug for at
ændre smtp-serveren skriver man den over.

Jeg vil nok vælge at lave en setSMTP i klassen i stedet. Ellers
ødelægges det hele jo af at define skal lave noget om, hvis man vil
bruge en lokal smtp-server, og så kan man ikke bare lige komme ud af det
igen, kan man?

--
Lars
www.fodboldenslegestue.dk   www.larsolesen.dk
www.discimport.dk      www.vih.dk

---

Lars Olesen wrote:
> Johan Holst Nielsen wrote:
>
>> I config filer...
>> Nu kender jeg ikke selve systemet dybere - skal den sende e-mail
>> gennem flere forskellige SMTP servere på samme server - eller er der
>> altid kun en SMTP server eller localhost smtp'en (mail funktionen)?
>
> Der vil oftest kun være en smtp-server på samme server.

Oftes? = Man skal tage højde for begge dele ;)

>> Bare lige mit input - håbede du kunne bruge det til noget ;)
>
> Det kan jeg i hvert fald. Dit forslag er egentlig at bruge define() og
> lave en global indstilling i applikationen, og hvis man får brug for at
> ændre smtp-serveren skriver man den over.

Jah, det er at lave en global indstilling til klassen. Altså den som
klassen ved den skal bruge - hvis den skal bruge SMTP men SMTP'en ikke
er defineret.

> Jeg vil nok vælge at lave en setSMTP i klassen i stedet. Ellers
> ødelægges det hele jo af at define skal lave noget om, hvis man vil
> bruge en lokal smtp-server, og så kan man ikke bare lige komme ud af det
> igen, kan man?

Jo... Problemet er blot man skal huske hvornår man skal inkludere den
ene forhold til den anden... eneste krav ved det jeg skrev var at du
_skal_ inkludere den lokale config fil før klassen.

$useSMTP variablen er så den der fortæller hvorvidt der skal bruges SMTP
eller ej...

Hvis $useSMTP er false - vil den aldrig røre den globale (ikke at
forveksle med PHP's $_GLOBALS) SMTP server. Men kun se på hvad du selv
skriver...

Dvs... der er nogle cases...

1. Du inkludere først lokal config og derefter klassen. Lokal config
indeholder $useSMTP true eller false.
1a. $useSMTP er true... du laver ikke en konstant der hedder
SMTP_SERVER = den bruger den global definerede.
1b. $useSMTP er false... du laver ikke en konstant der hedder
SMTP_SERVER = den bruger mail() funktionen opsætning
1c. $useSMTP er true... du laver en konstant (...) den bruger den
lokal definerede
1d. $useSMTP er false... du laver en kontakt (...) den bruger den
lokal definerede (da den allerede definerer den inden tjekket).
2. Du inkluderer ingen lokal config men klassen. Da $useSMTP bliver sat
til true i global config filen bruger den den globale SMTP server.
3. Du inkludere FØRST klassen og derefter config filen - du får en fejl
da samme konstant bliver defineret 2 gang.


Reelt set kunne du også sagnes gøre det via setSMTP funktion - men det
er reelt det samme der sker...

<?php
class foo {
var $SMTPserver = null; //none = brug mail()
var $mailMethod = 'mail'; //mail | smtp
var $defaultSMTP = 'smtp.example.com';

function setSendingType($method='mail',$altSMTP='') {
if($method=='mail') {
$this->mailMethod='mail';
$this->SMTPserver=null;
}
elseif($method=='smtp') {
$this->mailMethod='smtp';
if($altSMTP=='') {
$this->SMTPserver = $this->defaultSMTP;
}
else {
$this->SMTPserver = $altSMTP;
}
}
else {
//smid en error om unknow method
}
}
}
?>


Det var jo også en mulighed :)
Det kræver dog lidt retning i klassen ;)

mvh
Johanm

---

[snip]

Tak for det grundige svar. Jeg forsøger lige at lave klassen færdig. Så
vender jeg tilbage. Det tager nok nogle dage :)

/lars

--
Lars
www.fodboldenslegestue.dk   www.larsolesen.dk
www.discimport.dk      www.vih.dk

---

[snip]

Jeg gad ikke lige læse mere, så jeg legede lidt med mail-klassen i stedet :)

For at gøre klassen så fleksibel som muligt er jeg kommet frem til at
det bedste måske er at skrive smtp-adressen ind, når klassen bruges.
Hvis man ikke gøre det bruger den i stedet mail-funktionen. Jeg har
bikset lidt med noget nu, som kan ses på:

www.fodboldenslegestue.dk/core/Email.php

Hvis der er nogen der har nogle ideer eller rettelser i øvrigt, er de
meget velkomne. Jeg benytter en klasse fra Zend til at sende SMTP-mails
(ingen grund til at opfinde den dybe tallerken alt for mange gange).
Selvom dette naturligvis også er set før, så er det et skridt i min
OOP-øvelse :)

Altså ideer eller dumheder må gerne påpeges :)

/lars


--
Lars
www.fodboldenslegestue.dk   www.larsolesen.dk
www.discimport.dk      www.vih.dk

---

> www.fodboldenslegestue.dk/core/Email.php

Flyttede lige filen til

www.fodboldenslegestue.dk/core/ShowEmail.php

--
Lars
www.fodboldenslegestue.dk   www.larsolesen.dk
www.discimport.dk      www.vih.dk

---

Lars Olesen wrote:

> > www.fodboldenslegestue.dk/core/Email.php
>
> Flyttede lige filen til
>
> www.fodboldenslegestue.dk/core/ShowEmail.php

Uden at grave i det - er der en grund til du ikke bruger PEAR klassen?
Den er genial i mange tilfælde - med mindre man virkelig selv ønsker at
skrive sin kode ;)

http://pear.php.net/mail_mime

mvh
Johan

---

Johan Holst Nielsen wrote:
> Uden at grave i det - er der en grund til du ikke bruger PEAR klassen?
> Den er genial i mange tilfælde - med mindre man virkelig selv ønsker at
> skrive sin kode ;)
>
> http://pear.php.net/mail_mime

Det gør nu ikke noget. Jeg bruger ikke PEAR-klassen, fordi jeg ikke har
sat mig ind i den, og jeg er stadig på det stadium, hvor jeg gerne selv
vil skrive min kode, så jeg bliver ordentlig fortrolig med OOP. Når det
sker, har jeg tænkt på at bruge PEAR-klasserne, som jeg dog mener er
lidt 'bloated' og kan lidt for mange ting (de tager jo netop højde for
at klasserne skal kunne alt).

--
Lars
www.fodboldenslegestue.dk   www.larsolesen.dk
www.discimport.dk      www.vih.dk

---

Lars Olesen wrote:

> Johan Holst Nielsen wrote:
>
>> Uden at grave i det - er der en grund til du ikke bruger PEAR klassen?
>> Den er genial i mange tilfælde - med mindre man virkelig selv ønsker
>> at skrive sin kode ;)
>>
>> http://pear.php.net/mail_mime
>
> Det gør nu ikke noget. Jeg bruger ikke PEAR-klassen, fordi jeg ikke har
> sat mig ind i den, og jeg er stadig på det stadium, hvor jeg gerne selv
> vil skrive min kode, så jeg bliver ordentlig fortrolig med OOP. Når det
> sker, har jeg tænkt på at bruge PEAR-klasserne, som jeg dog mener er
> lidt 'bloated' og kan lidt for mange ting (de tager jo netop højde for
> at klasserne skal kunne alt).

Det er selvfølgelig altid rart at skrive sin egen kode (kan i hvert fald
give en vis "tilfredsstillese" for nørder som mig). Men af og til tænker
jeg også mere kapitalistisk/tidsmæssigt - og der er de en fordel.

Hvis det mere er for at lære PHP'en er det rigtigt, at det er nemmere og
bedre selv at lege sig frem til det rigtige resultat - og respekt for du
ikke vælger den nemme løsning ;)

PEAR klasserne har en fordel, at det er standardiseret - altså enhver
PHP udvikler bør reelt (indenfor en vis tid) have kendskab til klasserne
- desuden er mange af dem godt dokumenteret... hvilket også er den
fordel når mange udvikler sammen ;)

Lige præcis Mail Mime klassen synes jeg er ekstrem simpel og godt
opbygget (se doc. på
http://pear.php.net/manual/en/package.mail.mail-mime.php). Derfor jeg
anbefalede den - bruger den efterhånden selv en del - men vil ikke påstå
jeg er den der udnytter PEAR godt nok (endnu). Primært pga. jeg gennem
årens løb selv har bikset mine egne klasser sammen - så jeg har til
langt de meste. Men også pga. PEAR jo stadig er i en god udviklingsfase :)

Men sig endelig til hvis du har flere spørgsmål ;) Dit spørgsmål var
formuleret godt og grundig - og så er det jo altid en ekstra fornøjelse
at svare på sådanne spørgsmål :) :)

mvh
Johan

---

> Men sig endelig til hvis du har flere spørgsmål ;) Dit spørgsmål var
> formuleret godt og grundig - og så er det jo altid en ekstra fornøjelse
> at svare på sådanne spørgsmål :) :)

Will do, og tak for de gode svar.

/lars

--
Lars
www.fodboldenslegestue.dk   www.larsolesen.dk
www.discimport.dk      www.vih.dk