Archief - algoritme: kalender op website

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
d

dirtysniper

Legacy Member
yoo,
ik zou graag een kalender op mijn site krijgen die ik zelf kan aanpassen e.d.(niet een gewone tabel), ik zou dan onder een bepaalde datum bv. 'training' willen zetten. hoe kan ik dit best maken? :help:
s

stoffer

Legacy Member
Gebruik maken van een database, redelijk eenvoudig mbv mysql

Vb:
Je maakt tabellen 2004-2005-...
Je maakt in elke tabel 12 kolommen voor de maanden
In het juiste vak (1->31) kan je dan bvb training zetten

Anders kan je ook gewoon 1 tabel maken met als kolommen:
planning-dag-maand-jaar
En dan rangschikken volgens die kolommen
d

dirtysniper

Legacy Member
nee, ik maak mijn website via frontpage, ik wil dus eigenlijk een kalender die je ergens online kan opstellen/veranderen en dan via een code die je krijgt in mijn website plakken.
w

wajo

Legacy Member
jep normaal wel :) (ff ni naar de username kijken want zat bij ne vriend toen ek deze vraag gepost had)
D

DarkBone

Legacy Member
stoffer zei:
Gebruik maken van een database, redelijk eenvoudig mbv mysql

Vb:
Je maakt tabellen 2004-2005-...
Je maakt in elke tabel 12 kolommen voor de maanden
In het juiste vak (1->31) kan je dan bvb training zetten

Anders kan je ook gewoon 1 tabel maken met als kolommen:
planning-dag-maand-jaar
En dan rangschikken volgens die kolommen
Klik om te vergroten...

Ik zou toch eens snel iets gaan lezen over database normalisatie hoor, want hetgeen gij voorstelt, vooral het eerste dan, is om het zacht uit te drukken nogal slecht.
s

stoffer

Legacy Member
DarkBone zei:
Ik zou toch eens snel iets gaan lezen over database normalisatie hoor, want hetgeen gij voorstelt, vooral het eerste dan, is om het zacht uit te drukken nogal slecht.
Klik om te vergroten...

Dat 1e werkt toch perfect?
Het enige nadeel is dat de database reeds een vast is ingesteld denk ik
D

DarkBone

Legacy Member
stoffer zei:
Dat 1e werkt toch perfect?
Het enige nadeel is dat de database reeds een vast is ingesteld denk ik
Klik om te vergroten...
Ahja en dan 30 of 31 rijen naargelang de maand zeker ? En wat als ge meerdere afspraken hebt op een dag, en ge zou dus voor elke jaar 'dat er bestaat' een tabel moeten aanmaken?

Ik zeg het, informeer u eens over database normalisatie, een hele nieuwe wereld zal voor u open gaan. Probleem is dat veel mensen die met webscripting beginnen zonder programmeer opleiding of achtergrond, hier nog nooit van gehoord hebben (can't blame them). Maar neem van mij aan (net afgestudeerd als analyst/programmeur) dat dat niet de manier is waarop het gedaan moet worden.

Tuurlijk kunt ge da werkende krijgen... maar mooi, handig en flexibel is het allerminst.

Trouwens waarom denk je dat MySQL en andere RDBMs (Relational Database Management Systems) over veldtypen voor tijd & datum beschikken? Niet opdat gij dat nog es zou moeten simuleren met allerlei tabellen of velden die al dan niet jaar/dag of maand voorstellen hoor.

Ik denk maar aan de veldtypen:
DATE
DATETIME
TIMESTAMP
s

stoffer

Legacy Member
DarkBone zei:
Ahja en dan 30 of 31 rijen naargelang de maand zeker ? En wat als ge meerdere afspraken hebt op een dag, en ge zou dus voor elke jaar 'dat er bestaat' een tabel moeten aanmaken?
Klik om te vergroten...

Is toch niet moeilijk, in ieder veld steekt ge wat ge wilt gescheiden door een bepaald teken. Makkelijk te splitten + zeer makkelijk om het nodige veld op te roepen. Op zich zou men dus per jaar een tabel nodig hebben van telkens 12 kolommen. Vermits een online kalender zelden langer dan 2j meegaat is de grootte van de db dus miniem. Waarmee ik ook niet zeg dat het een goeie of elegante oplossing is, maar wel degelijk een oplossing die werkt en zeer overzichtelijk is.
C

Cakeman

Legacy Member
stoffer zei:
Is toch niet moeilijk, in ieder veld steekt ge wat ge wilt gescheiden door een bepaald teken. Makkelijk te splitten + zeer makkelijk om het nodige veld op te roepen. Op zich zou men dus per jaar een tabel nodig hebben van telkens 12 kolommen. Vermits een online kalender zelden langer dan 2j meegaat is de grootte van de db dus miniem. Waarmee ik ook niet zeg dat het een goeie of elegante oplossing is, maar wel degelijk een oplossing die werkt en zeer overzichtelijk is.
Klik om te vergroten...
Stel je even voor dat je een overzicht wilt van alle dagen waarop er een vergadering geweest is. In jouw oplossing moet je meerdere tabellen gaan doorzoeken (en vanaf welk jaar bestaat er een tabel?) en vervolgens uit een delimetered string het juiste veld gaan halen. Dat alles behalve efficiënt.

Je applicatie staat of valt vaak bij het ontwerp van je database.
s

stoffer

Legacy Member
Cakeman zei:
Stel je even voor dat je een overzicht wilt van alle dagen waarop er een vergadering geweest is. In jouw oplossing moet je meerdere tabellen gaan doorzoeken (en vanaf welk jaar bestaat er een tabel?) en vervolgens uit een delimetered string het juiste veld gaan halen. Dat alles behalve efficiënt.

Je applicatie staat of valt vaak bij het ontwerp van je database.
Klik om te vergroten...

Het gaat over een online kalender, niet over opzoeken é
In bepaalde situaties is die oplossing inderdad uiterst ongeschikt vandaar ook mijn 2e vb.
Maar wanneer het louter de bedoeling is om iets te tonen en toe te voegen (zoals op bvb clansites) volstaat dit toch?
D

DarkBone

Legacy Member
Gij haalt gewoon volledig heel de bestaansreden van RDMS onderuit, doe zo verder :niceone:

Ik maak er geen woorden meer aan vuil (scheidingstekens LOL).
D

DarkBone

Legacy Member
Alleen al het feit dat uw tabelnamen/kolomnamen/rijnummers variabel zullen zijn naargelang de datum, terwijl in een database makkelijk via SQL instructies op data kan gezocht worden. En een vaste structuur is sowieso nooit goed.
k

killgore

Legacy Member
je slaat in je db gewoon je events op, met een unix timestamp erbij

Je kalender stel je +/- zo samen:

PHP: 
$startdate = mktime(1,0,0,$maand,$dag,$jaar); //$maand, $dag en $jaar bereken je eventueel zelf naar gewenste dag van de maand
$enddate = mktime(1,0,0,$maand,$dag+$aantaldageninkalender+1,$jaar);

while($startdate < $enddate)
{
    $volgendedag = $startdate+86400
    //daglayout
    $sql = "SELECT * FROM kalenderevents WHERE unixtimestamp BETWEEN $startdate AND $volgendedag";
    //meer sql code om events vo die dag te outputten
   $startdate = $volgendedag
}
Nu ja, ik heb nog nooit een kalender gemaakt, maar dit idee kwam juist bij me op, lijkt me zeker geen zwaar script, is makkelijk aanpasbaar, te combineren met templates en vereist weinig zoekwerk in mysql tabellen e.d.

let wel op die 1 uur, 0 minuten, 0 seconden, is om zeker te zijn dat je in die dag zit ;). Ook einddag wordt hier er nog bijgerekend, wil je einddag weg, dan doe je gewoon die +1 in de mktime ervan weg ;)
a

aXl_

Legacy Member
ik heb ooit zo'n scriptje gemaakt

Just check the following links:

http://users.skynet.be/bs939021/filerommel/kalender-client.txt
http://users.skynet.be/bs939021/filerommel/kalender-item.txt

http://users.skynet.be/bs939021/filerommel/kalender-admin.txt
http://users.skynet.be/bs939021/filerommel/kalender-admin-modify.txt

en voor db-structuur

http://users.skynet.be/bs939021/filerommel/kalender-sql.txt

dit is gewoon 1 tbl in je database waar je events zijn opgeslagen. Op de site, wordt in het script gekeken welke dagen worden weergegeven, zijn er events voor die dagen dan word een link gegeven (met titel) naar een pop-up met gedetailleerdere beschrijving

check het script wel eens ivm security issues want het is al een tijdje geleden dat ik dit gemaakt heb. (ik bemerk zelfs dat ik nog gebruik maar van http_*_vars :wtf: check maar is goed voordat je het gebruikt)
o

orez

Legacy Member
ASP.NET Calender Control, nix is makkelijker :')

Nuja ok... ge moet er natuurlijk ook wel mee overweg kunnen. En ge moet dan direct op ASP.NET overgaan.
E

EryciusPuteanus

Legacy Member
Bij deze wil ik Darkbone bedanken voor zijn betoog over db normalisatie, ik zou er anders ook nogal over gepalaverd hebben ;)

>want nu zie ik niet echt in wrom sommige oplossingen die feitelijk eenvoudig zijn niet goed zijn

Ik zal 't zo simpel mogelijk proberen uit te leggen, specifiek voor dit geval: stel dat de Islam hier de komende jaar een enorm succes wordt, en ons land een schone islam itische theocratie wordt, dan gade daar nogal schoon staan met uw twaalf maanden... een islamitisch jaar is anders opgebouwd.

Om maar te zeggen: uw db moet zo gebouwd zijn dat ze makkelijk en snel aangepast kan worden.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan