(vi har fået lavet en mærkelig dobbelttråd, jeg prøver lige at føre den
sammen igen)
rasmus wrote:
>> Det er jo nok i virkeligheden svar på dine formatteringsspørgsmål,
>> og hvis det ikke er, skal du spørge i html-gruppen i stedet, det er
>> der html-formattering debatteres
. Konkret mener jeg listerne
>> skal lægges ind som lister <ul><li> osv i <div>-bokse - som evt
>> formatteres efter indholdet så en tilbehørsboks altid har noget
>> genkendeligt over sig osv.
>
> - jo, men: hvis der står en række ord i et felt og disse ord ikke
> skal skrives på en linje - men i en liste med en eller anden slags
> bullet-points
Sagen er at de ikke skal stå i et felt - hvis det skal være helt
rigtigt. Når det så er sagt så kan du selvfølgelig godt - om ikke andet
som en start ind til du kan overskue at udbygge - lægge alt fra
ingrediensliste til sidste punktum i forklaringen i et langt tekstfeldt
i databasen, og så skal du selvfølgelig have html-formatteringen ind
undervejs.
Altså: et system hvor man har hvert ord der skal ind i en specifik
formattering (fx <li></li>) i en tabelcelle for sig selv i databasen, er
_stærkt_ fordi man ikke vil skulle ændre på de store mængder *indhold* i
databasen bare fordi man vil ændre lidt på *præsentationen*.
Det betyder også at du kan ændre præsentation for mange sider 1 sted
(endnu mere radikalt end med CSS
)
Det er ydermere stærkt fordi det er data-logisk stringent, det sparer
plads fordi man ikke skal skrive det samme mange gange, og det kører
stærkt i afvikling hvis det er lavet ordentligt.
MEN det kræver indsigt og planlægningsarbejde, og lige her i oprettelsen
kræver det mere arbejde. Lige så snart du har 50 opskrifter inde (min
nuværende samling tæller vist et par tusinde, men det er altså ikke i et
online-system
), har du for længst sparet den tid som du må bruge
ekstra her i starten, og når du når til næste projekt som skal bruge
database...
>>> tillægsspørgsmål: "salat med røget hellefisk" kunne jo også
>>> rubriceres under
>>> "salat" - kan jeg bare skrive både Fisk og Salat i mit
>>> kategirifelt?
Det fik jeg ikke svaret på sidste gang. Der er to muligheder i db'en: du
kan lave det med en SET (lidt i stil med ENUM, men kan have flere værdier)
*opskrifter*
|id|navn|kategori|
|1 |Helleflyndersalat|salat, fiskeret|
eller du kan lave det med en separat tabel til kategorier
*opskrifter*
|id|navn|
|1 |Helleflyndersalat|
*opskriftskategorier*
|id|kategori|
|1 |fiskeret|
|2 |salat|
*opskrift_kategori* (relationstabel som bruges til at finde kategori ud
fra id)
|opskriftId|kategoriId|
|1|1|
|1|2|
- jeg har ikke sat et id for denne tabel, det udgør de to tilsammen.
Fidusen ved den sidste løsning er at det er lettere at ændre på
kategorier (både navn og at tilføje). Ulempen er at man skal spørge
efter endnu en relation når man skruer sin SQL sammen.
>> Du skal lave en standardside som hedder opskrift.php, som så henter
>> den opskrift, hvis id du medsender når du linker til siden, fx. <a
>> href="opskrift.php?opskr=22">Stygstuvet Søtunge</a>
>
> - ok, det lysner lidt. Siden opskrift.php er jo bare en kopi af min
> index.php med diverse menuer og logo mv ... men med noget standard
> for tabeludtrækket???
Her kan jeg ikke helt følge dig
> Så der linkes altså først til feks. fisk.php.
Ja - afhængigt af hvad den side er for en - du kan også bare have en
side der hedder oversigt.php eller opskriftskategorier.php, hvorpå der
så fremkommer lister af opskrifter afhængigt af hvad brugeren trykker
for nogle valg ind.
Det er mere automatiseret, men giver mindre kønne URL'er (fordi der
kommer en masse parametre op i url'en). Det er pænere, som du foreslår,
at lave en side som henter listen af fiskeopskrifter, en anden som
henter listen af salater osv. De to siders kodeindhold vil ligne
hinanden meget, men der kan du bare lave genbrug af funktioner til at
hante en opskriftsliste ud osv.
> Der hentes så alle poster fra tabellen (altså den ene af dem - den
> der har et id og et overskriftsfelt (navn)). Denne stump php sættes
> så ind i et link nogenlunde således:
>
> <a href="opskrift.php?navn=[php-kode: skriv id fra
> tabelposten]>[php-kode: skriv overskrift fra tabelposten]</a><br>
jeps
>> Siden viser så de data som står i databasetabellen opskrifter under
>> id 22, incl overskrift/titel osv. Den skal nok hente ingredienser
>> fra en anden tabel, tilknyttet med relationer.
Jeps
> - yes ... og det er så en anden tabel, hvor posterne ud over sit eget
> id, får et (f.esk) ekstra_id / overskrift_id, som jeg så kalder på
> siden sammen med indholdet af de øvrige tabeller?
Det forstod jeg ikke hvad du vil bruge til?
Altså - siden
> opskrift.php har så nogenlunde dette indhold:
>
> php-kode: Skriv indhold af "overskrift" fra id=x (det indsættes vel
> fra linket eller hvad)
ja
<br> php-kode: Skriv indhold af "introduktion"
> fra id=x <br> php-kode: Skriv i en liste indhold af alle ord i
> "ingredienser" fra tabel_2 hvor overskrift_id=id i tabel_1 <br>
Hvorfor laver du det på overskrifts-id - opskriften har jo et glimrende
id som snildt kan bruges her?
>> Det lyder som om du ikke har styr på den ende af programmeringen
>> endnu - hvis jeg læser rigtigt hvad det angår så prøv at kode dig
>> igennem en tutorial om bogsamlinger eller videobånd (de er std),
>> det giver altså lidt rutine og overblik som er ret lækkert at have
>> når man skal til sit eget projekt
>
> - hehe, du har helt ret. Jeg har tygget igennem diverse turtorials og
> jeg har skam også fået en lille gæstebog til at virke. Det er jo nok
> en god ide at gennemskrive et eksempel, der virker - men o´mvendt er
> det sjovere at kaste sig ud i eget projet (om end det går lidt hårt
> ud over folkene i nyhedsgruppen)
Det er rigtigt og rigtigt - sagen er bare at selv om vi bruger _timer_
på at hjælpe dig så vil der være ting som du først får _godt_ med noget
erfaring. Hvis du drager den erfaring, og gør de fejl, på et
øve-projekt, så slipper du for at se på den halvskidte kode mange gange
i dine projekter. Du kan sikkert ikke komme udenom at lave halvskidte
løsninger, men du kan komme langt af vejen uden om
>> Med lidt god programmering og en stak if-sætninger skulle du let
>> kunne trække alle typer opskrifter ind på samme side uden at det
>> kommer til at virke forkert.
>
> - ikke forstået ...
Det gik ud på at jeg forestiller mig at der er elementer af siden
opskrift.php - såsom 'sovs' som hører til i nogle opskrifter, men ikke i
alle. Du skal så have siden til ikke at vise boksen 'sovs' hvis det er
en salat-side (og i praksis er det nok let gjort ved at sige at den boks
kun skal vises hvis der er en sovs at skrive om i den
)
>>> sovs - den sovs findes allerede i tabellen - hvordan linker man
>>> til den
>>> den vises sammen med opsrkiften på Laksebøffer?
>>
>> Ved at man laver en relationstabel som hedder tilbehør. Her sætter
>> man så relationen at id 22 skal have vist id 45 i boksen 'sovse',
>> under 'tilbehør' eller lignende...
>
> - jeg tror jeg er med, men jeg tror også jeg venter med den del. Dels
> er der ikke så mange opskrifter, at jeg ikke kan overkomme at skrive
> HELE opskriften og dels brækker jeg sikkert nakken på det alligevel.
> Desuden kan man vel relativt nemt udbygge på den måde senere hen ikke
> sandt?
jo - det er ca lige så let at udbygge og ændre som det er at gøre det
fra starten, så hvis du har travlt kan du godt sørge for at få noget op
at køre, og så modellere. Dog under forbehold af at det, der er lavet,
er lavet godt og stringent, og helst med udbyggelsesmulighederne i
tankerne. Dvs: hellere tegne hele databasen op som den skal se ud i den
perfekte version, og så evt 'misbruge' nogle felter og tabeller og lade
andre stå tomme lige nu. Derved risikerer du nemlig ikke at du pludselig
skal lave tabellernes struktur om og lægge data ind forfra.
> - ok. Altså hellere et ekstra felt i tabellen som man kan præsentere
som man
> lyster end noget html/css formatteret tekst i et felt?
ja - fordi det sandsynligvis gør at det felt bliver formatteret ens hver
gang. Det kan du også ordne med CSS, men hvis du nu skal ændre
klassenavnet er det en fordel ikke at skulle søg-og-erstatte dig igennem
hele db-indholdet.
>>*opskrifter* (synes jeg er bedre
)
>>| id | navn |
>>| 1 | Laksebøffer i ovn |
>>| 2 | Biksemad |
>>| 3 | Champignonsovs | ..osv..
>
> - den er jeg med på! (det kan jeg da vist nemlig finde ud af )
Eksempler er ofte godt
>>*ingredienser*
>>| id | ingrediens |
>>| 1 | basilikum |
>>| 2 | mel | osv
>
>
> - sådan en tror jeg også jeg kan lave ... det er altså en tabel, men
alle de
> ingredienser jeg kan finde på at bruge
nemlig
>>*blandinger* (Lars' 2: opskriftoplysninger)
>>| id | opskrift_id | ingrediens_id | maengde (tidl 'antal/vægt') |
>>| 1 | 1 | 2 | 400 gr |
>
>
> - ok, atlså en tabel med titlerne på opskrifterne og en anden tabel
med en
> mulliard forskellige indgredienser. Men til laksebøffen skal der jo
ikke kun
> bruges 400 gram mel. Det skal jo være en håndfuld Ingrediens-id'er. Og
> hvordan sidder jeg og finder ud af hvilken id løg har og hvilken id
safran
> har og hvilken id oksetykkam i tern har osv har?
I første omgang vælger du selv. Dernæst gør du det ved at lave et
interface til at skrive opskrifter ind, som skriver til databasen. Der
kan du så vælge en opskrift, og tilføje ingredienser fra en
dropdownliste (eller flere) som har hentet alle mulige ingredienser ud,
og som sætter id når den skriver til databasen selv om det du ser i dit
interface bare er navne for ingredienserne.
Jeg vil dog være oprigtig nok til at indvende at det næsten er et
projekt i sig selv at lave det interface som du skal skrive det hele ind
i. Du kan overveje at gemme det (til du bliver frusteret nok over at
finde ingrediens-id'er
). Du kan også overveje at finde et
opensource-opskriftssystem (det må findes) som du kigger dybt i så du
ikke skal lære hver teknisk funktionalitet ved inddateringssystemet
forfra
. Der er et par her:
<
http://www.hotscripts.com/cgi-bin/search.cgi?bool=AND&query=recipes&catid=2>
og den nederste ser umiddelbart brugbar ud :)
>>*opskriftsrelatering*
>>| opskrift_id | relateret_opskrift_id | relationsforhold |
>>| 1 | 3 | sovs |
> - jeg tror jeg forstår, men er også lidt skræmt ...
Ja - det kan blive grumt hvis du skal have 1 SQL sætning til at hive
opskrift + ingredienser + tilbehørsopskrifter og deres ingredienser * op
til (sovs + salat + brød + grønsager = 4) 4 tilbehørsopskrifter... :-/
Det kan dog til gengæld let løses ved at liste tilbehørsopskrifterne og
så blot trække dem ud som opskrifter længere nede på samme opskriftsside
>>nej nej nej - begynd på w3schools.com med deres SQL-tutorial, så kommer
>>du hurtigt derudaf
>
>
> - hehe jeg vil gøre et forsøg ... om end det nok først bliver i morgen.
fair nok
mvh
Jesper Brunholm