---

## PHP-ARTIKELSYSTEM ##

Jeg har lavet et artikelsystem i PHP.

## KLASSER OG FILER
www.larsolesen.dk/artikler/class.artikel.txt
www.larsolesen.dk/artikler/index.txt
www.larsolesen.dk/artikler/noegleord.txt
www.larsolesen.dk/artikler/forfatter.txt
www.larsolesen.dk/artikler/noegleord_upload.txt

www.larsolesen.dk/artikler/database.txt

## LOGIN
side:    www.larsolesen.dk/artikler/login.php
login:   eksperten
pass:   eksperten

Jeg har forsøgt at lave det objektorienteret, så det er let at
flytte
fra server til server, fordi jeg skal bruge det på to af mine
egne sider.

Jeg er meget interesseret i al den feedback, I har mulighed for
at give
på fremgangsmåden, men jeg har især to problemer.

# håndtering af post og get
# håndtering af rettigheder

## HÅNDTERING AF POST OG GET - til StoreData() og DisplayForm()
og Execute()

Artikelsystemet består hovedsageligt af index.php, som kalder
klasser i class.artikel.php,
og al opdatering mv. foregår fra samme fil, men er distribueret
ud i forskellige klasser.
Det gør, at der kommer en masse forskellige GET og POST fra
formularer og querystring, som
systemet skal håndtere.

Jeg er imidlertid ikke helt tilfreds med den måde jeg har fået
gjort det på, for det betyder, at
mange af klasserne skal hente de
samme GET og POST og i øvrigt tjekke om det er nødvendigt - det
kan da ikke være særligt effektivt.

Kan samme funktionalitet implementeres på anden måde?

## BRUGEN AF RETTIGHEDER
De fleste klasser har brug for at vide, hvilke rettigheder
brugeren har, men er det smart at
starte et rettighedsobjekt op i hver klasse, eller skal jeg gøre
det på en anden måde?

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Lars Olesen <lars@legestue.net> writes:

> Jeg har forsøgt at lave det objektorienteret, så det er let at
> flytte fra server til server, fordi jeg skal bruge det på to af mine
> egne sider.

Det argument forstår jeg ikke. Derudover er det IMHO fornuftigt at
benytte objekt orientering så snart man er ude og helt trivielle
ting.

> Jeg er meget interesseret i al den feedback, I har mulighed for at
> give på fremgangsmåden

Nu er det forholdsvis meget kode, og det er ikke helt nemt at
gennemskue, hvordan det hænger sammen - men her er et par
kritikpunkter:

- Du har flere klasser med kun en eller to metoder. Dette er normalt
tegn på skidt design.

- I index.txt bruger du variablen $tjek to gange i træk, men med vidt
forskellig betydning. Det er forvirrende.

- Nedarvning kan være farligt og bør kun bruges i de tilfælde, hvor
der virkelig er tale om en specialisering. Med "class FlytElement
extends Position" lyder dette ikke som værende tilfældet.

- Din HTML, SQL og PHP er blandet forfærdeligt godt sammen. En
seperation af disse vil gøre programmet meget nemmere at arbejde med
i fremtiden.

> men jeg har især to problemer.
>
> # håndtering af post og get
> # håndtering af rettigheder
>
> ## HÅNDTERING AF POST OG GET - til StoreData() og DisplayForm() og
> Execute()
>
> Artikelsystemet består hovedsageligt af index.php, som kalder
> klasser i class.artikel.php, og al opdatering mv. foregår fra samme
> fil, men er distribueret ud i forskellige klasser. Det gør, at der
> kommer en masse forskellige GET og POST fra formularer og
> querystring, som systemet skal håndtere.
>
> Jeg er imidlertid ikke helt tilfreds med den måde jeg har fået gjort
> det på, for det betyder, at mange af klasserne skal hente de samme
> GET og POST og i øvrigt tjekke om det er nødvendigt - det kan da
> ikke være særligt effektivt.
>
> Kan samme funktionalitet implementeres på anden måde?

Singleton design mønsteret vil muligvis kunne anvendes
her. Alternativt kan du hente dine request variable ud et centralt
sted og så sende dem rundt i koden ved metodekald.

> ## BRUGEN AF RETTIGHEDER
> De fleste klasser har brug for at vide, hvilke rettigheder brugeren
> har, men er det smart at starte et rettighedsobjekt op i hver
> klasse, eller skal jeg gøre det på en anden måde?

Et alternativ kunne være at lave et kombineret factory og "dørvogter"
objekt, der står for adgangen til data. Altså, så du ikke instantierer
dine objekter direkte i "klient" koden, men kalder dørvogteren og
beder den om objekter.

Jeg håber du er blevet inspireret

--
Med venlig hilsen
- Jacob Atzen

---

Først vil jeg skrive, at jeg er blevet meget inspireret af din
tilbagemelding. Tak for det.

> - Du har flere klasser med kun en eller to metoder. Dette er normalt
> tegn på skidt design.

På phppatterns.com skriver han netop at en klasse kun skal kunne noget
ganske specifikt, så det har jeg forsøgt at holde mig til.

http://www.phppatterns.com/index.php/article/articleview/49/1/1/

Kan du give mig eksempler på, hvilke klasser som måske er overflødige og
skal slås sammen?

> - I index.txt bruger du variablen $tjek to gange i træk, men med vidt
> forskellig betydning. Det er forvirrende.

Ja, det kan du have fuldstændig ret i. Det vil jeg lave om i løbet af
dagen i dag.

> - Nedarvning kan være farligt og bør kun bruges i de tilfælde, hvor
> der virkelig er tale om en specialisering. Med "class FlytElement
> extends Position" lyder dette ikke som værende tilfældet.

Ja, du har vist ret. Den udnytter snarere klassen end udvider den. Det
skal naturligvis også laves om.

> - Din HTML, SQL og PHP er blandet forfærdeligt godt sammen. En
> seperation af disse vil gøre programmet meget nemmere at arbejde med
> i fremtiden.

Hvordan tænker du, at de kan adskilles?

> > men jeg har især to problemer.
> >
> > # håndtering af post og get
> > # håndtering af rettigheder

> Singleton design mønsteret vil muligvis kunne anvendes
> her. Alternativt kan du hente dine request variable ud et centralt
> sted og så sende dem rundt i koden ved metodekald.

Jeg vil lige kigge lidt på Singleton-design-mønsteret. Jeg går ud fra, at
du mener noget i stil med følgende:

http://www.phppatterns.com/index.php/article/articleview/75/1/1/

Det jeg måske tænker er at hente alle request-variable ind i en
Controller-klasse, som så sender dem rundt ved metodekaldene. Så har jeg
imidlertid et problem, for variablene skal ikke nødvendigvis sendes på
samme tid ift. eksekveringen af koden.

> > ## BRUGEN AF RETTIGHEDER
> Et alternativ kunne være at lave et kombineret factory og "dørvogter"
> objekt, der står for adgangen til data. Altså, så du ikke instantierer
> dine objekter direkte i "klient" koden, men kalder dørvogteren og
> beder den om objekter.

Altså,

class Dørvogter {

$var mRights;

function Dørvogter ()
{
$this->mRights = $_SESSION['rettigheder'];
}

function OpretElement ()
{
if ($this->mRights)
{
return OpretElement();
}
}

}

/lars

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

"Lars Olesen" <lars@legestue.net> skrev i en meddelelse
news:bnd5vo$k76$1@sunsite.dk...
> > - Din HTML, SQL og PHP er blandet forfærdeligt godt sammen. En
> > seperation af disse vil gøre programmet meget nemmere at arbejde med
> > i fremtiden.
>
> Hvordan tænker du, at de kan adskilles?

Du har svjv 2 muligheder:
1. brug (eksisterende) klasser til generering af HTML. Dette vil spare plads
og fjerne den, i php-sammenhænge, grimme HTML-syntax. På den måde forøges
overskueligheden.
2. du kan også holde output helt udenfor klasserne, altså lade dem om
databehandling alene. Dette vil dog kræve en meget kraftig omskrivning og
passer altså ikke særligt godt med systemet som du har valgt at skrive det.
Det vil dog gøre systemet ekstremt fleksibelt med henblik på integrering i
andre systemer eller fx PHP-Gtk.

Mine 2 øre.

--
Mvh. Jonas Delfs, http://delfs.dk

---

> Du har svjv 2 muligheder:
> 1. brug (eksisterende) klasser til generering af HTML. Dette vil spare
plads
> og fjerne den, i php-sammenhænge, grimme HTML-syntax. På den måde forøges
> overskueligheden.

Øh, her tror jeg ikke at jeg er helt med? Hvilke er de eksisterende klasser?

> 2. du kan også holde output helt udenfor klasserne, altså lade dem om
> databehandling alene. Dette vil dog kræve en meget kraftig omskrivning og
> passer altså ikke særligt godt med systemet som du har valgt at skrive det.
> Det vil dog gøre systemet ekstremt fleksibelt med henblik på integrering i
> andre systemer eller fx PHP-Gtk.

Det gør nu ikke noget, at jeg skal skrive systemet om. Det skrives også for
at jeg skal lære noget :) Jeg har tænkt over det, men hvordan skal en klasse,
som kun står for databehandling outputte data? Som arrays eller hvad? Og hvor
skal data så vises?

Hvis jeg kan gøre systemet mere fleksibelt og kunne gøre det til genstand for
udvidelse eller integrering, vil det være godt :)

Med venlig hilsen
Lars

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

"Lars Olesen" <lars@legestue.net> skrev i en meddelelse
news:bneppg$79b$1@sunsite.dk...
> > Du har svjv 2 muligheder:
> > 1. brug (eksisterende) klasser til generering af HTML. Dette vil spare
> plads
> > og fjerne den, i php-sammenhænge, grimme HTML-syntax. På den måde
forøges
> > overskueligheden.
>
> Øh, her tror jeg ikke at jeg er helt med? Hvilke er de eksisterende
klasser?

Beklager, den var lidt tvetydig. Jeg mener at der til formålet findes
klasser til håndtering af HTML. Eksempelvis er PEAR (pear.php.net) et forsøg
på at lave sådanne genbrugelige værktøjer - også til HTML. Et eksempel kunne
være HTML_Table-klassen som genererer HTML-tabeller på en "intelligent" måde
og lader dig på den måde spare plads samt adskille PHP og HTML.

> > 2. du kan også holde output helt udenfor klasserne, altså lade dem om
> > databehandling alene. Dette vil dog kræve en meget kraftig omskrivning
og
> > passer altså ikke særligt godt med systemet som du har valgt at skrive
det.
> > Det vil dog gøre systemet ekstremt fleksibelt med henblik på integrering
i
> > andre systemer eller fx PHP-Gtk.
>
> Det gør nu ikke noget, at jeg skal skrive systemet om. Det skrives også
for
> at jeg skal lære noget :) Jeg har tænkt over det, men hvordan skal en
klasse,
> som kun står for databehandling outputte data? Som arrays eller hvad? Og
hvor
> skal data så vises?

Du skal se om ikke du kan holde alt hvad der har direkte med output at gøre
for sig, og så det der ikke har for sig. Som minimum i hver sine funktioner,
men hvordan jeg mener det bedst gøres i dit tilfælde kan jeg ikke give dig
et svar på uden at have sat mig bedre ind i din kode. Det kommer helt an på
systemets struktur og størrelse, men det ser ud til at dig og Jacob har en
fornuftig diskussion vedr. opdeling i klasser.
På denne måde vil du nemt kunne bruge andre systemer til at outputte dit
data.

--
Mvh. Jonas Delfs, http://delfs.dk

---

> Jeg mener at der til formålet findes
> klasser til håndtering af HTML.

Ja, jeg har kigget lidt på dem. Synes måske PEAR er lidt voldsomt, men
det er god at få ideer af, og jeg er ved at forsøge at stykke noget
sammen på:

www.larsolesen.dk/lib/class.html.txt

> Du skal se om ikke du kan holde alt hvad der har direkte med output at gøre
> for sig, og så det der ikke har for sig. Som minimum i hver sine funktioner,
> men hvordan jeg mener det bedst gøres i dit tilfælde kan jeg ikke give dig
> et svar på uden at have sat mig bedre ind i din kode. Det kommer helt an på
> systemets struktur og størrelse, men det ser ud til at dig og Jacob har en
> fornuftig diskussion vedr. opdeling i klasser.
> På denne måde vil du nemt kunne bruge andre systemer til at outputte dit
> data.

Det er jeg - kraftigt inspireret af Phppatterns.com DAO-objekt - ved at
forsøge at gøre på www.larsolesen.dk/artikler/class.article.txt og
www.larsolesen.dk/artikler/indexny.txt.

Jeg går ud fra, at det er noget i den retning, at du mener?

/lars

---

Lars Olesen <lars@legestue.net> writes:

> > - Du har flere klasser med kun en eller to metoder. Dette er
> > normalt tegn på skidt design.
>
> På phppatterns.com skriver han netop at en klasse kun skal kunne
> noget ganske specifikt, så det har jeg forsøgt at holde mig til.
>
> http://www.phppatterns.com/index.php/article/articleview/49/1/1/

Jeg kan ikke finde det præcise sted i artiklen, hvor han omtaler
det. Men jeg tror du har misforstået ham en smule. Efter min
overbevisning, bør man tilstræbe at, hver klasse kun har et
"ansvar". Dette er ikke ækvivalent med at "kunne noget ganske
specifikt".

Forskellen ligger i abstraktionsniveauet. F.eks. vil jeg mene det er
fornuftigt at have en klasse der har ansvaret for at holde styr på din
artikelsamling. Men jeg mener ikke, at det er fornuftigt at have en
klasse, der har ansvar for at indsætte en artikel i samlingen.

En tommelfingerregel er at klasser bør være navneord,
f.eks. artikelsamling og metoder bør være udsagnsord, f.eks. indsæt.

> Kan du give mig eksempler på, hvilke klasser som måske er overflødige og
> skal slås sammen?

Et par kandidater til flytning er "sletLink" og "ArtikelMenu" - de har
begge kun en metode, som gør noget ganske trivielt. "sletLink" ville
jeg flytte til din "ArtikelLinks" klasse.

> > - Din HTML, SQL og PHP er blandet forfærdeligt godt sammen. En
> > seperation af disse vil gøre programmet meget nemmere at arbejde med
> > i fremtiden.
>
> Hvordan tænker du, at de kan adskilles?

Nogen klasser til håndtering af præsentation (HTML), nogen klasser til
håndtering af data (SQL) og så dine algoritmer i andre
klasser. Forestil dig, at du ville udskifte din database med en anden
database med en anden SQL syntax. Eller at du ville skifte fra HTML
til XHTML eller WAP eller... Som det er nu ville du være nødt til at
gå hele din kode igennem for at finde de relevante steder at
ændre. Målet er, at du f.eks. kan hive hele din database backend ud og
erstatte med en ny, uden at skulle ændre nævneværdigt i resten af dit
program. Hvordan det gøres smart er så spørgsmålet

> > Singleton design mønsteret vil muligvis kunne anvendes
> > her. Alternativt kan du hente dine request variable ud et centralt
> > sted og så sende dem rundt i koden ved metodekald.
>
> Jeg vil lige kigge lidt på Singleton-design-mønsteret. Jeg går ud fra, at
> du mener noget i stil med følgende:
>
> http://www.phppatterns.com/index.php/article/articleview/75/1/1/

Ja, det er noget i den stil.

> Det jeg måske tænker er at hente alle request-variable ind i en
> Controller-klasse, som så sender dem rundt ved metodekaldene. Så har jeg
> imidlertid et problem, for variablene skal ikke nødvendigvis sendes på
> samme tid ift. eksekveringen af koden.

Hvad med at bruge en statisk klasse i stedet. Altså en klasse der ikke
kan instantieres. Eksempelvis kalde den som følger fra klient klassen:

RequestController::getSomeVar();

Så slipper du for at smide en masse parametre rundt i dit program.

> Altså,
>
> class Dørvogter {
[snip]

Ja, noget i den retning.

--
Med venlig hilsen
- Jacob Atzen

---

Det er guldkorn det her. Rigtig god hjælp - det må jeg sige!

> Efter min
> overbevisning, bør man tilstræbe at, hver klasse kun har et
> "ansvar".

Jeg ser hvad du mener, og vil allerede nu begynde at ændre praksis. Jeg vil
sørge for at klasserne i stedet får et ansvar, snarere end kan noget ganske
specifikt.

> Forskellen ligger i abstraktionsniveauet. F.eks. vil jeg mene det er
> fornuftigt at have en klasse der har ansvaret for at holde styr på din
> artikelsamling. Men jeg mener ikke, at det er fornuftigt at have en
> klasse, der har ansvar for at indsætte en artikel i samlingen.

Men at OpretArtikel har jo et specifikt ansvar, ligesom RedigerArtikel har
det. Hvor skal jeg så gøre af funktionerne til at oprette en artikel? Jeg er
med på at SletArtikel bør indkorporeres i RedigerArtikel.

> En tommelfingerregel er at klasser bør være navneord,
> f.eks. artikelsamling og metoder bør være udsagnsord, f.eks. indsæt.

Det er en god tommelfingerregel, som jeg med det samme vil tjekke om mine
klasser lever op til.

> > Kan du give mig eksempler på, hvilke klasser som måske er overflødige og
> > skal slås sammen?
>
> Et par kandidater til flytning [snip] "ArtikelMenu"

Hvor ville du så gøre af sådan en klasse. Jeg har skrevet en klasse, fordi
systemet skal bruges to forskellige steder. Det er en af årsagerne til, at
jeg har smidt det hele ind i klasser, for så kan jeg lave en masse ændringer
bagved, bare jeg stadig sørger for at outputte de rigtige ting, uden at noget
går i stykker :)

> Nogen klasser til håndtering af præsentation (HTML), nogen klasser til
> håndtering af data (SQL) og så dine algoritmer i andre
> klasser. Forestil dig, at du ville udskifte din database med en anden
> database med en anden SQL syntax. Eller at du ville skifte fra HTML
> til XHTML eller WAP eller... Som det er nu ville du være nødt til at
> gå hele din kode igennem for at finde de relevante steder at
> ændre. Målet er, at du f.eks. kan hive hele din database backend ud og
> erstatte med en ny, uden at skulle ændre nævneværdigt i resten af dit
> program. Hvordan det gøres smart er så spørgsmålet

Det er jeg helt med på. Det ville være smart, men så bliver jeg fx nødt til
at skille Artikel op i to, så det bliver ArtikelSql og ArtikelHtml. Er det
sådan noget du tænker på?

> Hvad med at bruge en statisk klasse i stedet. Altså en klasse der ikke
> kan instantieres. Eksempelvis kalde den som følger fra klient klassen:
>
> RequestController::getSomeVar();

En klasse der ikke kan instanieres, det har jeg sgu' ikke forstand på. Du har
vel ikke et link, som forklarerer lidt mere om det? Eller lige forklarer det
lidt mere i dybden, så vil jeg være glad :)

/lars

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Lars Olesen <lars@legestue.net> writes:

> > Forskellen ligger i abstraktionsniveauet. F.eks. vil jeg mene det
> > er fornuftigt at have en klasse der har ansvaret for at holde styr
> > på din artikelsamling. Men jeg mener ikke, at det er fornuftigt at
> > have en klasse, der har ansvar for at indsætte en artikel i
> > samlingen.
>
> Men at OpretArtikel har jo et specifikt ansvar, ligesom
> RedigerArtikel har det. Hvor skal jeg så gøre af funktionerne til at
> oprette en artikel? Jeg er med på at SletArtikel bør indkorporeres i
> RedigerArtikel.

Jeg ville foreslå dig en ArtikelBestyrer klasse. Denne kunne så
indeholde metoder til at oprette, slette, ændre, osv. Så kunne du have
en artikel klasse, der indeholdt information om den enkelte artikel.

> > > Kan du give mig eksempler på, hvilke klasser som måske er overflødige og
> > > skal slås sammen?
> >
> > Et par kandidater til flytning [snip] "ArtikelMenu"
>
> Hvor ville du så gøre af sådan en klasse. Jeg har skrevet en klasse, fordi
> systemet skal bruges to forskellige steder. Det er en af årsagerne til, at
> jeg har smidt det hele ind i klasser, for så kan jeg lave en masse ændringer
> bagved, bare jeg stadig sørger for at outputte de rigtige ting, uden at noget
> går i stykker :)

Det mål, opnår du kun, hvis du får koblet dine ting løsere end du har
i dag. Hvor du skal flytte den hen, tja, det må du finde ud af

> > Nogen klasser til håndtering af præsentation (HTML), nogen klasser til
> > håndtering af data (SQL) og så dine algoritmer i andre
> > klasser. Forestil dig, at du ville udskifte din database med en anden
> > database med en anden SQL syntax. Eller at du ville skifte fra HTML
> > til XHTML eller WAP eller... Som det er nu ville du være nødt til at
> > gå hele din kode igennem for at finde de relevante steder at
> > ændre. Målet er, at du f.eks. kan hive hele din database backend ud og
> > erstatte med en ny, uden at skulle ændre nævneværdigt i resten af dit
> > program. Hvordan det gøres smart er så spørgsmålet
>
> Det er jeg helt med på. Det ville være smart, men så bliver jeg fx nødt til
> at skille Artikel op i to, så det bliver ArtikelSql og ArtikelHtml. Er det
> sådan noget du tænker på?

Jeg tænker nok endnu mere abstrakt. Hvis det var mig der skulle lave
det, ville jeg starte med at lave den del af systemet, der handler om
databehandlingen. Bagefter ville jeg så lave et "plugin", så jeg kunne
hente og gemme mine data i en database. Og til sidst ville jeg så lave
et præsentationslag, der kunne præsentere mine data i f.eks. HTML.
Jeg er desværre ikke erfaren nok til at kunne sige, hvordan dette
skulle laves smart.

Problemet med at lave ArtikelSQL og ArtikelHTML er, at de lyder til at
være hårdt bundet op på Artikel. På den måde bryder du med
OO-princippet om indkapsling. Kun Artikel bør vide, hvordan den hænger
sammen indvendig. Resten af verden bør kun have brug for at kende dens
public metoder (dens interface). ArtikelSQL og ArtikelHTML lyder som
om de har brug for at kende en hel del til det indre i Artikel.

> > Hvad med at bruge en statisk klasse i stedet. Altså en klasse der ikke
> > kan instantieres. Eksempelvis kalde den som følger fra klient klassen:
> >
> > RequestController::getSomeVar();
>
> En klasse der ikke kan instanieres, det har jeg sgu' ikke forstand på. Du har
> vel ikke et link, som forklarerer lidt mere om det? Eller lige forklarer det
> lidt mere i dybden, så vil jeg være glad :)

<http://dk2.php.net/manual/en/keyword.paamayim-nekudotayim.php>

--
Med venlig hilsen
- Jacob Atzen

---

Jacob Atzen wrote in dk.edb.internet.webdesign.serverside.php:
> Jeg ville foreslå dig en ArtikelBestyrer klasse. Denne kunne så
> indeholde metoder til at oprette, slette, ændre, osv. Så kunne du have
> en artikel klasse, der indeholdt information om den enkelte artikel.

Aha, ja det kunne jeg jo gøre. Det er en god ide, så har den kun et ansvar, og det
er at bestyre artikler!

> > Hvor ville du så gøre af sådan en klasse. Jeg har skrevet en klasse, fordi
> > systemet skal bruges to forskellige steder. Det er en af årsagerne til, at
> > jeg har smidt det hele ind i klasser, for så kan jeg lave en masse ændringer
> > bagved, bare jeg stadig sørger for at outputte de rigtige ting, uden at noget
> > går i stykker :)
>
> Det mål, opnår du kun, hvis du får koblet dine ting løsere end du har
> i dag. Hvor du skal flytte den hen, tja, det må du finde ud af

Nu skriver du nok koble tingene løsere :) Min tanke er, at selve filen til visning
af artiklen stort set bare kan se sådan her ud:

$artikel = new Artikel($id);
$artikel->OpdaterKlik();
echo $artikel->VisArtikel();

Men det er måske ikke smart? Tænkte ellers at det ville være ufattelig smart :)

> Jeg tænker nok endnu mere abstrakt. Hvis det var mig der skulle lave
> det, ville jeg starte med at lave den del af systemet, der handler om
> databehandlingen. Bagefter ville jeg så lave et "plugin", så jeg kunne
> hente og gemme mine data i en database. Og til sidst ville jeg så lave
> et præsentationslag, der kunne præsentere mine data i f.eks. HTML.

Jeg har en klasse, som håndterer databehandlingen, som jeg kalder DB_Sql(); Den
sørger for alle kontakter med databasen. Fra de andre klasser kalder jeg den så
sådan her:

$sql = "SELECT navn FROM artikel WHERE id = " . $_GET['id'];
$db = new DB_Sql($sql);
while ($db->next_record()) {
print $db->f(navn);
}

Mit "plugin" er så Artikel, som har brug for $id for at vælge den rigtige artikel.
Men det er måske ikke sådan, du mener?

Præsentationslaget er indtil nu koblet sammen med plug-in'et, og det er
naturligvis ikke så smart. Det må jeg se at få gjort noget ved. Skal bare lige
tænke lidt over, hvordan det egentlig gøres smart :)

> Problemet med at lave ArtikelSQL og ArtikelHTML er, at de lyder til at
> være hårdt bundet op på Artikel. På den måde bryder du med
> OO-princippet om indkapsling.

Ja, det kan du have ret i.

> <http://dk2.php.net/manual/en/keyword.paamayim-nekudotayim.php>

Det tror jeg faktisk måske er en god måde at gøre det med rettighederne på, men
den kan vist også bruges til at håndtere post og get, hvis jeg ikke tager meget
fejl :)

Tak for hjælpen.

/lars

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Lars Olesen <lars@legestue.net> writes:

> Jacob Atzen wrote in dk.edb.internet.webdesign.serverside.php:
>
> > Jeg ville foreslå dig en ArtikelBestyrer klasse. Denne kunne så
> > indeholde metoder til at oprette, slette, ændre, osv. Så kunne du
> > have en artikel klasse, der indeholdt information om den enkelte
> > artikel.
>
> Aha, ja det kunne jeg jo gøre. Det er en god ide, så har den kun et
> ansvar, og det er at bestyre artikler!

Nemlig

> Nu skriver du nok koble tingene løsere :) Min tanke er, at selve
> filen til visning af artiklen stort set bare kan se sådan her ud:
>
> $artikel = new Artikel($id);
> $artikel->OpdaterKlik();
> echo $artikel->VisArtikel();
>
> Men det er måske ikke smart? Tænkte ellers at det ville være
> ufattelig smart :)

Det er en måde. En anden måde ville være:

$artikel = new Artikel($id);
$taeller = new KlikTaeller();
$taeller->OpdaterKlik($artikel);
$fremviser = new ArtikelHTMLfremviser();
echo $fremviser->VisArtikel($artikel);

På denne måde har du fjernet din tælle funktion fra din artikel (hvor
den IMHO faktisk ikke har noget at gøre). Ligeledes har du løstkoblet
din fremvisning, så du supernemt kan skifte fremviser, bare ved at
ændre ArtikelHTMLfremviser til f.eks. ArtikelSMSfremviser.

Problemet med ovenstående fremgangsmåde er, at du skal finde en smart
måde for din fremviser at hive de nødvendige data ud af artiklen
på. Og her mener jeg _ikke_ getters og setters.

> > Jeg tænker nok endnu mere abstrakt. Hvis det var mig der skulle
> > lave det, ville jeg starte med at lave den del af systemet, der
> > handler om databehandlingen. Bagefter ville jeg så lave et
> > "plugin", så jeg kunne hente og gemme mine data i en database. Og
> > til sidst ville jeg så lave et præsentationslag, der kunne
> > præsentere mine data i f.eks. HTML.
>
> Jeg har en klasse, som håndterer databehandlingen, som jeg kalder
> DB_Sql(); Den sørger for alle kontakter med databasen. Fra de andre
> klasser kalder jeg den så sådan her:
>
> $sql = "SELECT navn FROM artikel WHERE id = " . $_GET['id'];
> $db = new DB_Sql($sql);
> while ($db->next_record()) {
> print $db->f(navn);
> }
>
> Mit "plugin" er så Artikel, som har brug for $id for at vælge den
> rigtige artikel. Men det er måske ikke sådan, du mener?

Det lyder lidt omvendt på mig. Hvad sker der den dag du ikke længere
vil bruge SQL til at lagre dine data? Jeg ville separere datahentning
og lagring ud fra dataadministration. F.eks. ved hjælp af et DAO:

<http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html>

Det skal selvfølgelig helst gøres så smart at du ikke behøver lave
ændringer i din datatilgang, hvis din artikel ændrer struktur.

> > Problemet med at lave ArtikelSQL og ArtikelHTML er, at de lyder
> > til at være hårdt bundet op på Artikel. På den måde bryder du med
> > OO-princippet om indkapsling.
>
> Ja, det kan du have ret i.
>
> > <http://dk2.php.net/manual/en/keyword.paamayim-nekudotayim.php>
>
> Det tror jeg faktisk måske er en god måde at gøre det med
> rettighederne på, men den kan vist også bruges til at håndtere post
> og get, hvis jeg ikke tager meget fejl :)

Det kan den givetvis

--
Med venlig hilsen
- Jacob Atzen

---

Jacob Atzen wrote:
> Det er en måde. En anden måde ville være:
>
> $artikel = new Artikel($id);
> $taeller = new KlikTaeller();
> $taeller->OpdaterKlik($artikel);
> $fremviser = new ArtikelHTMLfremviser();
> echo $fremviser->VisArtikel($artikel);
>
> På denne måde har du fjernet din tælle funktion fra din artikel (hvor
> den IMHO faktisk ikke har noget at gøre). Ligeledes har du løstkoblet
> din fremvisning, så du supernemt kan skifte fremviser, bare ved at
> ændre ArtikelHTMLfremviser til f.eks. ArtikelSMSfremviser.
>
> Problemet med ovenstående fremgangsmåde er, at du skal finde en smart
> måde for din fremviser at hive de nødvendige data ud af artiklen
> på. Og her mener jeg _ikke_ getters og setters.

Nu har jeg så objektet $artikel, som jeg vil føde til OpdaterKlik() og
til VisArtikel(). Kunne objektet $artikel så ikke bestå af et array?

Eksempelvis:

$array['id']
$array['overskrift']

osv.

Nåeh, nej, så bliver min Tæller spoleret, for så kan den ikke vide, hvad
det er den skal opdatere (fx kunne tælleren jo netop også bruges til at
opdatere klik på nøgleordene :)) Ja, jeg er ved at følge din tankegang
:) Eller måske er jeg bare ved at begynde at tænke ordentligt
objekt-orienteret :)

Huha, det er svært :) Synes egentlig at mit system var nogenlunde smart,
men det smarte er ved at være gået af det :)

Jeg rekapitulerer lige, som jeg har forstået vores diskussion indtil nu:

// OM OOP //////////////////////////////////////////

* Klasser skal kun have et ansvar
* Klasser bør hedde navneord, mens metoderne bør
Være udsagnsord.
* Konstruktoren skal ikke gøre noget i sig selv,
men blot instantiere klassen.
* Userinterface bør være separat fra dataadgang i
redigeringsklasserne.

// KLASSER /////////////////////////////////////////

class Artikel {

   // @param $id (int) Artikelid
   // @return (objekt) Returnerer artikeloplysninger
   function Artikel($id) {
      // henter Artikeloplysningerne
      return $artikeloplysninger;
   }

}

class ArtikelHtmlFremviser {

   
   function ArtikelHtmlFremviser() {
   }
   
   // @param $artikel (objekt) Objekt med oplysninger om artikel
   function VisArtikel($artikel) {
      // viser artiklen som html.
      // problemet er hvordan $artikel skal gøres klar til at    
      // vises
   }
}


class KlikTaeller {
   function KlikTaeller() {
   }
   @param $what (objekt)
   function OpdaterKlik($what) {
      // Skal finde ud af hvad der skal opdateres med et klik
      // problemer er at finde ud af, hvad der skal opdateres
      // er det nøgleord, artikel eller?
   }
}

class ArtikelBestyrer {
   // @param $artikel (objekt) $artikelobjektet
   function ArtikelBestyrer($artikel) {
   }
   function RedigerArtikel() {
      if (Rettigheder::HentRettigheder() == 'redaktør') {
         // giv mulighed for at redigere artikel
      }
   }
   function SletArtikel() {}
   function OpretArtikel() {
      // Denne funktion hører vel ikke hjemme her, da
      // opret Artikel netop ikke har noget ID endnu?
   }
}

class Rettigheder {
// Statisk klasse
   function HentRettigheder() {
      return $rettigheder;
   }
}

class Controller {
// statisk klasse
   function Controller() {
   }
   function GetAction() {
      return $_POST['action'];
   }
}

// BRUG AF KLASSERNE /////////////////////////////////

if (isset(Controller:GetAction()))
{
   $artikel = new Artikel($id);
   $bestyrer = new ArtikelBestyrer();
   $bestyrer->GemArtikel($id);
   $bestyrer->RedigerArtikel($id);
   
}

$artikel = new Artikel($id);
$taeller = new KlikTaeller();
$taeller->OpdaterKlik($artikel);

$fremviser = new ArtikelHTMLfremviser();
echo $fremviser->VisArtikel($artikel);


/lars

---

Lars Olesen <lsolesen@hotmail.com> writes:

> Nu har jeg så objektet $artikel, som jeg vil føde til OpdaterKlik() og
> til VisArtikel(). Kunne objektet $artikel så ikke bestå af et array?
>
> Eksempelvis:
>
> $array['id']
> $array['overskrift']
>
> osv.
>
> Nåeh, nej, så bliver min Tæller spoleret, for så kan den ikke vide,
> hvad det er den skal opdatere (fx kunne tælleren jo netop også bruges
> til at opdatere klik på nøgleordene :)) Ja, jeg er ved at følge din
> tankegang :) Eller måske er jeg bare ved at begynde at tænke
> ordentligt objekt-orienteret :)

Egentlig bør tæller være fuldstændig ligeglad med, hvordan dit artikel
objekt ser ud indeni. Det eneste tæller skal bruge fra artiklen er en
eller anden form for identifikation. F.eks.:

$taeller->taelOp($artikel);

Og så i Taeller klassen:

function taelOp($artikel) {
$this->taelKlik[$artikel->getId()]++;
}

Under forudsætning af, at det er sådan du holder styr på dine klik.

> Huha, det er svært :) Synes egentlig at mit system var nogenlunde
> smart, men det smarte er ved at være gået af det :)

Jamen det er jo bare tegn på, at du er blevet klogere, og det var vel
det du gerne ville?

> * Klasser skal kun have et ansvar
> * Klasser bør hedde navneord, mens metoderne bør
> Være udsagnsord.
> * Konstruktoren skal ikke gøre noget i sig selv,
> men blot instantiere klassen.
> * Userinterface bør være separat fra dataadgang i
> redigeringsklasserne.

Jeg ved ikke helt, om jeg bryder mig om "redigeringsklasserne".
Jvf. det du selv skriver som punkt 2. Redigering er ikke et navneord.

> // KLASSER /////////////////////////////////////////

[snip]
> class ArtikelHtmlFremviser {
>
>    
>    function ArtikelHtmlFremviser() {
>    }
>    
>    // @param $artikel (objekt) Objekt med oplysninger om artikel
>    function VisArtikel($artikel) {
>       // viser artiklen som html.
>       // problemet er hvordan $artikel skal gøres klar til at
>       // vises
>    }
> }
>
>
> class KlikTaeller {
>    function KlikTaeller() {
>    }
>    @param $what (objekt)
>    function OpdaterKlik($what) {
>       // Skal finde ud af hvad der skal opdateres med et klik
>       // problemer er at finde ud af, hvad der skal opdateres
>       // er det nøgleord, artikel eller?
>    }
> }

Når jeg tænker over det, virker det som om du har et problem med
abstraktionsniveauet, hvis du både ønsker at tælle kliks på artikler
og nøgleord. Man klikker jo ikke på en artikel, man klikker på et link
til en artikel. Men måske er det nærmere antallet af artikel visninger
du ønsker at registrere?

> class ArtikelBestyrer {
>    // @param $artikel (objekt) $artikelobjektet
>    function ArtikelBestyrer($artikel) {
>    }

Hvorfor tager din artikel bestyrer konstruktør en artikel som
argument? Det tyder på, at du mener hver artikel har sin egen
bestyrer, hvilket vel ikke var meningen?

>    function RedigerArtikel() {
>       if (Rettigheder::HentRettigheder() == 'redaktør') {
>          // giv mulighed for at redigere artikel
>       }
>    }
>    function SletArtikel() {}
>    function OpretArtikel() {
>       // Denne funktion hører vel ikke hjemme her, da
>       // opret Artikel netop ikke har noget ID endnu?
>    }
> }
>
> class Rettigheder {
> // Statisk klasse
>    function HentRettigheder() {
>       return $rettigheder;
>    }
> }
>
> class Controller {
> // statisk klasse
>    function Controller() {
>    }
>    function GetAction() {
>       return $_POST['action'];
>    }
> }
>
> // BRUG AF KLASSERNE /////////////////////////////////
>
> if (isset(Controller:GetAction()))
> {
>    $artikel = new Artikel($id);
>    $bestyrer = new ArtikelBestyrer();
>    $bestyrer->GemArtikel($id);
>    $bestyrer->RedigerArtikel($id);
>    
> }

Her ville jeg nok vælge:

$artikel = new Artikel($id);
   $bestyrer = new ArtikelBestyrer();
   $bestyrer->GemArtikel($artikel);
   $bestyrer->RedigerArtikel($artikel);

$id mener jeg bør være noget der i så høj grad som muligt holdes
indeni dine artikel objekter. Ellers har du delvist ødelagt
indkapslingen ved at eksponere en implementationsdetalje for dine
klienter.

Omvendt er det rimelig at argumentere for, at netop bestyreren kan
have en større grad af viden om det den bestyrer, da den formentlig
indeholder samlingen af artikler. Hmm...

--
Med venlig hilsen
- Jacob Atzen

---

> Jeg ville separere datahentning
> og lagring ud fra dataadministration. F.eks. ved hjælp af et DAO:
>
> <http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html>

Så vidt jeg forstår DAO efter at have læst lidt videre, så skal jeg lave
en klasse som sørger for al dataadgang til fx Artiklen og kladen den
ArtikelDao - denne klasse skal så indeholde:

class ArtikelDao {

   function GetArtikler() {}
   function GetArtikel() {}

}

class Artikler og
class Artikel kalder så ArtikelDao for at få sine oplysninger.

/lars

---

Lars Olesen <lsolesen@hotmail.com> writes:

> Så vidt jeg forstår DAO efter at have læst lidt videre, så skal jeg
> lave en klasse som sørger for al dataadgang til fx Artiklen og kladen
> den ArtikelDao - denne klasse skal så indeholde:
>
> class ArtikelDao {
>
>    function GetArtikler() {}
>    function GetArtikel() {}
>
> }
>
> class Artikler og
> class Artikel kalder så ArtikelDao for at få sine oplysninger.

Ja, det er en mulighed.

Og med risiko for at modsige mig selv...

Hvis ambitionsniveauet er lidt lavere, kan du også indlejre dine
database kald direkte i dit Artikel objekt:

class Artikel {
...
function hent($database) {
// Hent fra database
}

function gem($database) {
// Foretag lagring
}
}

Evt. kan du indlejre/kalde "hent" i/fra konstruktøren. Det vigtigste
er efter min mening, at du har indkapslet artikels interne
information sådan så klienter til artikel ikke behøver bekymre sig om,
hvordan den er implementeret.

--
Med venlig hilsen
- Jacob Atzen

---

> Hvis ambitionsniveauet er lidt lavere, kan du også indlejre dine
> database kald direkte i dit Artikel objekt:

Ambitionsniveauet er højt :) Evnerne er knap så store :(

/lars

---

Jacob Atzen wrote:
>
> Det lyder lidt omvendt på mig. Hvad sker der den dag du ikke længere
> vil bruge SQL til at lagre dine data? Jeg ville separere datahentning

i 29 ud af 30 systemer(hvis ikke flere) vil jeg hævde at man aldrig går
fra SQL til noget andet. Så at bruge tid på at abstrahere på så højt
niveau virker som overkill for mig - især i forbindelse med web-indhold...

--
Mvh. Nezar Nielsen
http://fez.dk

---

> i 29 ud af 30 systemer(hvis ikke flere) vil jeg hævde at man aldrig går
> fra SQL til noget andet. Så at bruge tid på at abstrahere på så højt
> niveau virker som overkill for mig - især i forbindelse med web-indhold...

Det kan du måske have ret i, men der er stor grund til fx at abstrahere
mht. visning, idet indhold efterhånden skal vises på PDA'er,
Mobiltelefoner, XML-læsere og meget mere, så her er abstraktionen i
hvert fald god... og når den laves her, kan man også lige så godt lave
den på datatilgangen, for så har man et fleksibelt system, som bliver
let at opdatere, hvis man nu er den ene.

/lars

---

Lars Olesen wrote:

> hvert fald god... og når den laves her, kan man også lige så godt lave
> den på datatilgangen, for så har man et fleksibelt system, som bliver
> let at opdatere, hvis man nu er den ene.

Tjah, hvis man har nok tid kan man jo lave alting :)
Problemet er ikke så meget at få sit fine system til at kunne hente en
eller anden given ressource(fx. en artikel) ud fra et id, problemerne
kommer mere, hvis man fx. gerne vil kunne søge i sine artikler - så skal
din data-access klasse også kunne have et api til at søge efter bimser,
som skal være "bredt" nok til at det også vil virke den dag man går fra
sql til dba-filer.. og så vil man også gerne kunne sortere resultaterne
og lave paginering af dem osv..

Jeg har ikke set eksempler på systemer der er fine nok til at kunne
sådan nogle ting.. (måske metabase eller et lignende abstraktionslag kan..)

--
Mvh. Nezar Nielsen
http://fez.dk

---

> Tjah, hvis man har nok tid kan man jo lave alting :)

Det har du helt ret i :)

> Problemet er ikke så meget at få sit fine system til at kunne hente en
> eller anden given ressource(fx. en artikel) ud fra et id, problemerne
> kommer mere, hvis man fx. gerne vil kunne søge i sine artikler - så skal
> din data-access klasse også kunne have et api til at søge efter bimser,
> som skal være "bredt" nok til at det også vil virke den dag man går fra
> sql til dba-filer.. og så vil man også gerne kunne sortere resultaterne
> og lave paginering af dem osv..

Ja, så bliver det pludselig vanskeligt. Jeg har ikke forstand på, om der er
store forskelle, så den diskussion, kan jeg ikke rigtig deltage i.

/lars

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Nezar Nielsen <tumpen@fez.dk> writes:

> Jacob Atzen wrote:
> > Det lyder lidt omvendt på mig. Hvad sker der den dag du ikke længere
> > vil bruge SQL til at lagre dine data? Jeg ville separere datahentning
>
> i 29 ud af 30 systemer(hvis ikke flere) vil jeg hævde at man aldrig
> går fra SQL til noget andet. Så at bruge tid på at abstrahere på så
> højt niveau virker som overkill for mig - især i forbindelse med
> web-indhold...

Jeg tvivler skam også meget på at Lars nogensinde vil bruge andet end
MySQL til sin database. Mit indtryk er også nærmere, at Lars er
interesseret i at se, hvor pænt objekt orienteret han kan gøre sit
system. Og som øvelse mener jeg, at det er relevant at se, hvor
meget fleksibilitet man kan opnå.

--
Med venlig hilsen
- Jacob Atzen

---

> Jeg tvivler skam også meget på at Lars nogensinde vil bruge andet end
> MySQL til sin database. Mit indtryk er også nærmere, at Lars er
> interesseret i at se, hvor pænt objekt orienteret han kan gøre sit
> system. Og som øvelse mener jeg, at det er relevant at se, hvor
> meget fleksibilitet man kan opnå.

Lars er ret enig :) Det er netop øvelsen :) Gad vide om det nogensinde
lykkes?

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Jacob Atzen wrote in dk.edb.internet.webdesign.serverside.php:
> En tommelfingerregel er at klasser bør være navneord,
> f.eks. artikelsamling og metoder bør være udsagnsord, f.eks. indsæt.

Huha, har lige gennemgået mine klasser, og jeg har nogle stykker, som falder
for denne regel :(

=> så falder mine klasser RedigerElement og RedigerArtikel jo pladask til
jorden. Måske bør metoderne heri flyttes over i klasserne Element og Artikel?
Kan man så stadig godt sige at klasserne har et ansvar?

/lars

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Lars Olesen wrote:
> Jacob Atzen wrote in dk.edb.internet.webdesign.serverside.php:
>
>>En tommelfingerregel er at klasser bør være navneord,
>>f.eks. artikelsamling og metoder bør være udsagnsord, f.eks. indsæt.
>
>
> Huha, har lige gennemgået mine klasser, og jeg har nogle stykker, som falder
> for denne regel :(
>
> => så falder mine klasser RedigerElement og RedigerArtikel jo pladask til
> jorden.

Jeg sad lige og tænkte på det i din foregående post

> Måske bør metoderne heri flyttes over i klasserne Element og Artikel?
> Kan man så stadig godt sige at klasserne har et ansvar?

Ja da - især hvis de hedder ArtikelProcessor (eller ArtikelBogholder) og
i den stil. Ansvaret kan godt være til stede uden at være synligt i
navnet, men det er smartest at det er synligt.

mvh

Jesper Brunholm

---

Jesper Brunholm wrote in dk.edb.internet.webdesign.serverside.php:
> Ja da - især hvis de hedder ArtikelProcessor (eller ArtikelBogholder) og
> i den stil. Ansvaret kan godt være til stede uden at være synligt i
> navnet, men det er smartest at det er synligt.

Men man kommer alligevel til at stå tilbage med en klasse, som pludselig kan en
masse:

vise, redigere, slette og oprette artikler, men det gør måske ikke noget?

/lars

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Lars Olesen wrote:
> Men man kommer alligevel til at stå tilbage med en klasse, som pludselig kan en
> masse:
>
> vise, redigere, slette og oprette artikler, men det gør måske ikke noget?

Hvis 'vise' er lig med 'hente' så er det helt i tråd med det jeg mener.

Hvis det er 'vise den frem på skærmen' så går det ikke - jeg er enig med
Jacob A i at du bør have HTML-produktionen skildt ud i et separat lag /
en separat klasse.

For mig at se er det helt logisk at sætte en klasse til at være
bestyrende mellemled imellem databasen og html'en, så du på en given
side, eksempel.php kalder ArtikelBogholder-klassen med ønske om en given
artikel. Den kalder så databasen, derefter html-modulet, og sender
output tilbage til din side .
Hvis du allerede var helt med på det jeg lige har beskrevet, så må du
undskylde, jeg var bare ikke sikker .

mvh

Jesper Brunholm

---

> Hvis 'vise' er lig med 'hente' så er det helt i tråd med det jeg mener.

Ok vise er nu lig med hente efter at mit hoved er ved at blive rigtigt
sporet ind.

> Hvis det er 'vise den frem på skærmen' så går det ikke - jeg er enig med
> Jacob A i at du bør have HTML-produktionen skildt ud i et separat lag /
> en separat klasse.

Ja, spørgsmålet er bare hvordan man lige kan gøre det :(

> Hvis du allerede var helt med på det jeg lige har beskrevet, så må du
> undskylde, jeg var bare ikke sikker .

Du skal sandelig ikke undskyld. Nu er jeg med på, at vi skal have tre
klasser:

- class Database, som sørger for at hente oplysninger
- class Artikel, som først kalder databasen med en sql og derfter kalder
ArtikelHtmlfremviser
- class ArtikelHtmlFremviser.

Uklarheden er dog stadig bør class Database i virkeligheden være class
ArtikelDatabase - eller menes de bare en generel databaseklasse? Jeg har
endnu ikke helt nået at læse om DAO, men gør det senere i dag, hvis det
har noget med det at gøre.

/lars

---

Lars Olesen <lars@legestue.net> writes:

> Huha, har lige gennemgået mine klasser, og jeg har nogle stykker, som falder
> for denne regel :(
>
> => så falder mine klasser RedigerElement og RedigerArtikel jo pladask til
> jorden. Måske bør metoderne heri flyttes over i klasserne Element og Artikel?
> Kan man så stadig godt sige at klasserne har et ansvar?

Jvf. min tidligere post. Og ja, jeg mener absolut stadig godt du kan
sige, at klasserne har et ansvar. Jeg vil dog mene, at du bør udskille
indholdet af dine Rediger-klasser i en "data" del og en userinterface
del.

Tænk på, hvad der ville ske, hvis du ville lave et andet interface til
din artikel samling. I dag ville du være nødt til at ændre mange
steder i din kode, da du har indkapslet userinterfacet direkte i dine
dataklasser. Hvis du derimod havde en seperat userinterface klasse,
ville du kunne nøjes med at skifte den ud, med en anden der havde
nogen tilsvarende metoder - eller sagt på OO'sk: Implementerede det
samme interface (ikke at forveksle med userinterface).

--
Med venlig hilsen
- Jacob Atzen

---

>Jeg vil dog mene, at du bør udskille
> indholdet af dine Rediger-klasser i en "data" del og en userinterface
> del.

Her går jeg ud fra, at du mener, at StoreData skal adskilles fra DisplayForm, men
jeg er vist ikke helt med på, hvad denne adskillelse i praksis kommer til at
betyde?

> Hvis du derimod havde en seperat userinterface klasse,
> ville du kunne nøjes med at skifte den ud, med en anden der havde
> nogen tilsvarende metoder - eller sagt på OO'sk: Implementerede det
> samme interface (ikke at forveksle med userinterface).

Altså hvad mener du, at den seperate userinterface-klasse skal indeholde, og hvad
bør datadelen indeholde?

/lars

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Lars Olesen <lars@legestue.net> writes:

> >Jeg vil dog mene, at du bør udskille
> > indholdet af dine Rediger-klasser i en "data" del og en userinterface
> > del.
>
> Her går jeg ud fra, at du mener, at StoreData skal adskilles fra
> DisplayForm,

Ja, det mener jeg absolut. Som jeg ser det, så har du grundlæggende et
artikelsystem. Dette system stiller kun en PHP grænseflade til
rådighed. Du kan så skrive en klient til dit artikelsystem, der
benytter de dele af grænsefladen, som tillader opdatering af indholdet
i systemet. Og du kan skrive en klient til systemet, der bare fremviser
indholdet.

Dit artikelsystem benytter så en database til at holde styr på sine
data. Dette kan modelleres som:

----------------------------------------------
| Fremvisningssystem | Administrationssystem |
----------------------------------------------
| Artikelsystem |
----------------------------------------------
| Database |
----------------------------------------------

> men jeg er vist ikke helt med på, hvad denne adskillelse i praksis
> kommer til at betyde?

Jeg er ikke sikker på jeg forstår spørgsmålet.

> > Hvis du derimod havde en seperat userinterface klasse,
> > ville du kunne nøjes med at skifte den ud, med en anden der havde
> > nogen tilsvarende metoder - eller sagt på OO'sk: Implementerede det
> > samme interface (ikke at forveksle med userinterface).
>
> Altså hvad mener du, at den seperate userinterface-klasse skal
> indeholde, og hvad bør datadelen indeholde?

En mulighed er at sige, at UserInterface stiller metoder til rådighed,
som datadelen "tegner" med.

Eksempelvis kunne man forestille sig (PHP5 syntax):

class HTMLWidgets implements Widget {
function createLabel($labelText) {
//
return $label;
}
}

class Article {
function draw($widget) {
return $widget->createLabel($this->someAttribute);
}
}

Du vil så fra klient koden - UserInterface - kunne kalde
$artikel->draw() med en eller anden form for Widget klasse/objekt. På
denne måde ved Artikel intet om, hvilken præsentations form du har
valgt. Og samtidig har du totalt indkapslet Artikel, så dit
UserInterface intet behøver vide om din Artikel.

Konsekvensen er, at hvis du senere hen ønsker at udskrive til et anden
medie, så skal du bare implementere en ny Widgets klasse. Og hvis din
artikel ændrer struktur (f.eks. får tilføjet eller fjernet et felt)
behøver du kun ændre i din draw metode. Er det ikke bare smart?

Der er dog et problem i ovenstående fremgangsmåde. For hvad nu, hvis
du ønsker mange forskellige views på din artikel. Aktuelt kunne man
forestille sig, at du både ville have:

- Et "oversigts" view, bare med titel og teaser
- Et fuldt view, der præsenterede hele artiklen
- Et administrativt view, hvor artiklen præsenterede sig selv på en
redigerbar måde.

Måske ville du i øvrigt gerne kunne redigere nogen metadata i
forbindelse med artikelredigeringen, som ingengang vises i det fulde
view.

Du skal altså bruge 3 forskellige view metoder. Men så begynder
Artikel klassen at føles lidt tung. Og så er det måske smartere at
have en ArtikelFremviser klasse, der implementerer disse views. Jeg er
ikke selv sikker på, hvordan dette gøres smartest, så jeg vil overlade
til dig at finde den pæneste løsning på dette problem

--
Med venlig hilsen
- Jacob Atzen

---

> Eksempelvis kunne man forestille sig (PHP5 syntax):
>
> class HTMLWidgets implements Widget {
> function createLabel($labelText) {
> //
> return $label;
> }
> }
>
> class Article {
> function draw($widget) {
> return $widget->createLabel($this->someAttribute);
> }
> }

Jeg har nu siddet og kigget rundt i Google i en times tid, og jeg har
ikke formået at finde en side, som giver nogle ordentlige eksempler på
hvordan man kan skrive sådan en HTMLWidget-ting - du har vel ikke en
reference?

> Du vil så fra klient koden - UserInterface - kunne kalde
> $artikel->draw() med en eller anden form for Widget klasse/objekt. På
> denne måde ved Artikel intet om, hvilken præsentations form du har
> valgt. Og samtidig har du totalt indkapslet Artikel, så dit
> UserInterface intet behøver vide om din Artikel.

Mit UserInterface er så fx ArtikelBestyrer?

> Konsekvensen er, at hvis du senere hen ønsker at udskrive til et anden
> medie, så skal du bare implementere en ny Widgets klasse. Og hvis din
> artikel ændrer struktur (f.eks. får tilføjet eller fjernet et felt)
> behøver du kun ændre i din draw metode. Er det ikke bare smart?

Jo, det er det, og det vil jeg også have (vræl, huha, det kommer til at
tage noget tid :))

> Der er dog et problem i ovenstående fremgangsmåde. For hvad nu, hvis
> du ønsker mange forskellige views på din artikel. Aktuelt kunne man
> forestille sig, at du både ville have:
>
> - Et "oversigts" view, bare med titel og teaser
> - Et fuldt view, der præsenterede hele artiklen
> - Et administrativt view, hvor artiklen præsenterede sig selv på en
> redigerbar måde.

Det kan man ikke bare forestille mig. Det er faktisk meningen, at det
nogenlunde skal være ligesom det er nu, bare med en ordentlig backend :)

> Du skal altså bruge 3 forskellige view metoder. Men så begynder
> Artikel klassen at føles lidt tung. Og så er det måske smartere at
> have en ArtikelFremviser klasse, der implementerer disse views. Jeg er
> ikke selv sikker på, hvordan dette gøres smartest, så jeg vil overlade
> til dig at finde den pæneste løsning på dette problem

Det vil jeg så forsøge :) Men endnu en gang tak for hjælpen. Det er lang
tid siden, at jeg er blevet så klog, så hurtigt. Har virkelig været i
gang med at kigge lidt på DAO, og så snart jeg har fundet ud af lidt om
HTMLWidgets, så tror jeg at jeg kan lave nogle omfattende strukturelle
ændringer i min OOP-kode.

/lars

---

Lars Olesen wrote:
>> Eksempelvis kunne man forestille sig (PHP5 syntax):
>>
>> class HTMLWidgets implements Widget {
>> function createLabel($labelText) {
>> // return $label;
>> }
>> }
>>
>> class Article {
>> function draw($widget) {
>> return $widget->createLabel($this->someAttribute);
>> }
>> }
>
>
> Jeg har nu siddet og kigget rundt i Google i en times tid, og jeg har
> ikke formået at finde en side, som giver nogle ordentlige eksempler på
> hvordan man kan skrive sådan en HTMLWidget-ting - du har vel ikke en
> reference?

Fandt noget som måske kan gøre det ud for en Widget. Se kildekoden på
www.larsolesen.dk/lib/class.html.txt.

Så kunne jeg gøre det således:

class ArtikelDao {
   // Laver et databaseobjekt
}

class Artikel {

   function Artikel($dao) {
      // holder styr på artikeloplysningerne
   }
   
}

class ArtikelFremviser {
   
   var $mArtikel;   

   function ArtikelFremviser($artikel) {
      $this->mArtikel;
   }
   function display() {
      $d = new HtmlOutput;
      while ($artikel = $this->mArtikel->next_record()) {
         // udnytter HtmlOutput-klassen
         print $d->h($artikel['overskrift'], 1);
         print $d->p($artikel['tekst']);
      }
   }
}

$dao = new ArtikelDao;
$artikel = new Artikel($dao);
$fremviser = new Artikelfremviser($artikel);

---

Lars Olesen <lsolesen@hotmail.com> writes:

> Så kunne jeg gøre det således:
>
> class ArtikelDao {
>    // Laver et databaseobjekt
> }
>
> class Artikel {
>
>    function Artikel($dao) {
>       // holder styr på artikeloplysningerne
>    }
>    
> }
>
> class ArtikelFremviser {
>    
>    var $mArtikel;   
>
>    function ArtikelFremviser($artikel) {
>       $this->mArtikel;
>    }
>    function display() {
>       $d = new HtmlOutput;
>       while ($artikel = $this->mArtikel->next_record()) {
>          // udnytter HtmlOutput-klassen
>          print $d->h($artikel['overskrift'], 1);
>          print $d->p($artikel['tekst']);
>       }
>    }
> }
>
> $dao = new ArtikelDao;
> $artikel = new Artikel($dao);
> $fremviser = new Artikelfremviser($artikel);

Ja, det var en mulighed. Evt. kan du prøve om du kan øge indkapslingen
af Artikel endnu mere, så ingengang ArtikelFremviser behøver at tilgå
Artikels interne variable.

--
Med venlig hilsen
- Jacob Atzen

---

Jacob Atzen wrote:
> Lars Olesen <lsolesen@hotmail.com> writes:
>>
>> $dao = new ArtikelDao;
>> $artikel = new Artikel($dao);
>> $fremviser = new Artikelfremviser($artikel);
>
> Ja, det var en mulighed. Evt. kan du prøve om du kan øge indkapslingen
> af Artikel endnu mere, så ingengang ArtikelFremviser behøver at tilgå
> Artikels interne variable.

Jeg ville nok gøre følgende:

$fremviser = new Artikelfremviser($artikel);
$fremviser->show();

Så dette er det eneste du skal skrive hver gang. Så sørger fremviseren selv
for at finde artikel klassen og artikelkassen finder selv artikeldao klassen
Håber du forstår.

De tre klasser:

#Artikelfremviser.class.php#
class Artikelfremviser{
var $data;
function Artikelfremviser($artikel){
$artikel = new Artikel($artikel);
$this->data = $artikel->hent();
}

function show(){
print $this->data;
}
}

#Artikel.class.php#
class Artikel {
var $dao;
var $data;
function Artikel($artikel){
$this->dao = new ArtikelDao;
}

function hent(){
$this->data = $this->dao->hentEllerNoget();
}
}

#ArtikelDao.class.php#
class ArtikelDao{
function ArtikelDao(){

}

function hentEllerNoget(){
// gør noget
}
}

Jeg har ikke lige læst hele tråden grundigt så måske er dette ikke helt det
optimale, men dog lige mit lille hurtige bud


--
Med venlig hilsen

Michael Jensen
Michael[SNABEL]ogj[PRIK]DK

---

Lars Olesen <lsolesen@hotmail.com> writes:

> > Eksempelvis kunne man forestille sig (PHP5 syntax):
> > class HTMLWidgets implements Widget {
> > function createLabel($labelText) {
> > // return $label;
> > }
> > }
> > class Article {
> > function draw($widget) {
> > return $widget->createLabel($this->someAttribute);
> > }
> > }
>
> Jeg har nu siddet og kigget rundt i Google i en times tid, og jeg har
> ikke formået at finde en side, som giver nogle ordentlige eksempler på
> hvordan man kan skrive sådan en HTMLWidget-ting - du har vel ikke en
> reference?

Nope. Har ikke set noget i den retning implementeret før. Har nu
heller ikke ledt efter det, så jeg skal ikke kunne sige om det
findes.

> > Du vil så fra klient koden - UserInterface - kunne kalde
> > $artikel->draw() med en eller anden form for Widget klasse/objekt.
>
> Mit UserInterface er så fx ArtikelBestyrer?

Nej. UserInterface vil være dit præsentationslag så vidt jeg lige kan
gennemskue.

--
Med venlig hilsen
- Jacob Atzen

---

> class HTMLWidgets implements Widget {
> function createLabel($labelText) {
> //
> return $label;
> }
> }
>
> class Article {
> function draw($widget) {
> return $widget->createLabel($this->someAttribute);
> }
> }

Kunne man forestille sig noget i retning af
www.larsolesen.dk/artikler/indexny.txt og
www.larsolesen.dk/artikler/class.article.txt.

Se resultatet på indexny.php.

Der er naturligvis ikke redigeringsværktøjer tilgænglige endnu, men
adskillelsen mellem datahentning og fremvisning? Jeg er klar over, at
html-klassen skal have nogle mere generelle betegnelser, så man
umiddelbart ville kunne overføre dem til XML mv og bare lave en ny
klasse med samme interface.

Bør man egentlig lave en særskilt "widget" til links, forms, tables
osv.? Det synes jeg, at det ser ud til, at PEAR gør.

/lars

---

Lars Olesen <lsolesen@hotmail.com> writes:

> Kunne man forestille sig noget i retning af
> www.larsolesen.dk/artikler/indexny.txt og

Jeg kan ikke helt gennemskue, hvad der foregår her.

> www.larsolesen.dk/artikler/class.article.txt.

Er ikke tilgængelig.

> Se resultatet på indexny.php.
>
> Der er naturligvis ikke redigeringsværktøjer tilgænglige endnu, men
> adskillelsen mellem datahentning og fremvisning? Jeg er klar over, at
> html-klassen skal have nogle mere generelle betegnelser, så man
> umiddelbart ville kunne overføre dem til XML mv og bare lave en ny
> klasse med samme interface.
>
> Bør man egentlig lave en særskilt "widget" til links, forms, tables
> osv.? Det synes jeg, at det ser ud til, at PEAR gør.

Det tror jeg ikke der er noget entydigt svar på. Det kommer an på,
hvad du forventer af dine widget klasser. Så længe de er overskuelige
og sammenhængende kan jeg ikke se noget problem i at holde dem i en
klasse, men hvis de begynder at blive uoverskuelige er det sikkert en
god ide at dele dem op.

--
Med venlig hilsen
- Jacob Atzen

---

> > Kunne man forestille sig noget i retning af
> > www.larsolesen.dk/artikler/indexny.txt og
> Jeg kan ikke helt gennemskue, hvad der foregår her.

Det kan jeg godt forstå, når du ikke kan tilgå, den følgende fil :)

> > www.larsolesen.dk/artikler/class.article.txt.
> Er ikke tilgængelig.

Ikke særlig dygtigt, men den er tilgængelig nu, og den er kraftigt
inspireret af tilgangen på www.phppatterns.com.

> > Se resultatet på www.larsolesen.dk/artikler/indexny.php.

/lars

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

> kraftigt
> inspireret af tilgangen på www.phppatterns.com.

Jeg har flyttet udviklingsversionen af systemet til
www.larsolesen.dk/articles/index.php, hvor kildekoden også vises.

Jeg har adskilt det kraftigt nu med et MVC-pattern og et databaseobjekt.
Jeg kommer lidt i problemer, for hvordan skal jeg få de enkelte
sideelementer indkorporeret i fx artiklen. Lige nu starter jeg
elementerne i selve artikelview-klassen, men det virker forkert. Desuden
virker det forkert at have en controller på elementerne, men det er
måske rigtigt nok ift. MVC-mønsteret?

Håber jeg ikke har trættet jer endnu :)

/lars