Daniel73 schreef:Ook op het gebied van website-layout (uitvoer) zijn er nog beperkingen door onder meer een gebrek aan een mogelijkheid om "frames" te gebruiken.
Daniel73 schreef:En er is het basisprincipe dat de site eerst gegenereerd moet worden, en dat het niet zomaar op een server kan draaien vanwege server-taalproblemen, etc. etc.
Lelijke Eend schreef:Die DVEGEN-sites zien er goed uit. Heel veel informatie, maar toch makkelijk door te bladeren met die 'volgende'-links. En zo te zien heb je als auteur heel veel controle over wat er met de data moet gebeuren.
Lelijke Eend schreef:Het ziet er wel ingewikkeld uit. Wat zou je precies willen met een McDrake-bibliotheek? Als het alleen gaat om het publiceren van artikelen en plaatjes, en niet zozeer om het inrichten van een ingewikkelde database, ben je misschien beter af met het schrijven van eenvoudige HTML-bestanden. Als je die goed organiseert, bijvoorbeeld met directories, maak je het een stuk makkelijker om iets te publiceren.
Lelijke Eend schreef:Daniel73 schreef:Ook op het gebied van website-layout (uitvoer) zijn er nog beperkingen door onder meer een gebrek aan een mogelijkheid om "frames" te gebruiken.
Waar heb je frames voor nodig? Ze worden in moderne sites nauwelijks nog gebruikt, omdat er veel nadelen aan zitten. Lees Why Frames Suck (Most of the Time), uit 1996 maar nog steeds vaak geciteerd.
Lelijke Eend schreef:Daniel73 schreef:En er is het basisprincipe dat de site eerst gegenereerd moet worden, en dat het niet zomaar op een server kan draaien vanwege server-taalproblemen, etc. etc.
Van tevoren genereren is een voordeel. De HTML-pagina's die je krijgt blijven altijd leesbaar. Als je de invoer 'live' op de server laat omzetten naar uitvoer, is het enige 'substantiële' dat je hebt niet-standaard invoer (bijvoorbeeld een MySQL-database met zelfbedachte structuur of tekstbestanden met een ingewikkelde DVEGEN-syntax) die over vijftig jaar misschien niet meer zomaar leesbaar is.
Lelijke Eend schreef:Het zou wel mooi zijn als je de invoer op de server zou kunnen laten omzetten naar HTML-pagina's. Maar het lijkt me niet noodzakelijk. Het enige wat je nodig hebt zijn de invoer-bestanden, het DVEGEN-programma en toegang tot de FTP-server, toch? Als je niet al te vaak iets nieuws hoeft te publiceren, moet het 'met de hand doen' niet zo'n groot probleem zijn.
Daniel73 schreef:Frames lijken mij handig voor een navigatie-bar die altijd in beeld blijft. En zijn frames niet dusdanig ingeburgerd zijn, dat men ze toch sowieso verwacht als mogelijkheid?
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<title>Navigatiebalk-voorbeeld</title>
<style type="text/css">
body {
margin-bottom: 3em;
}
p#navigatiebalk {
position: fixed;
left: 0;
right: 0;
bottom: 0;
margin: 0;
padding: 4px;
text-align: center;
background: yellow;
color: black;
border-top: 2px solid orange;
}
p#navigatiebalk a {
color: blue;
}
</style>
</head>
<body>
<p id="navigatiebalk"><a href="#">Vorige pagina</a> | <a href="#">Volgende pagina</a></p>
<p>Zet hier heel veel tekst en probeer de schuifbalk om te zien dat de navigatiebalk onderaan altijd zichtbaar is.</p>
</body>
</html>
Daniel73 schreef:Ook vraag ik me af hoe het programma om zou kunnen gaan met php, style sheets, java-scripts, active scripts, etc.
Daniel73 schreef:Tot dusver bestaat de samenwerking aan het project uit twee personen. Ik en een programmeur.
Daniel73 schreef:Het programma is helaas nog in wording. Onvoltooid dus.
Daniel73 schreef:Uitlegsite van DveGen
http://bolderbast.inducks.org/dvegen/
Lelijke Eend schreef:Als je een altijd zichtbare navigatiebalk wilt, kun je dat bijvoorbeeld met style sheets bereiken. Probeer de volgende HTML-code eens:
Zet hier heel veel tekst en probeer de schuifbalk om te zien dat de navigatiebalk onderaan altijd zichtbaar is.
Daniel73 schreef:Ook vraag ik me af hoe het programma om zou kunnen gaan met php, style sheets, java-scripts, active scripts, etc.
Lelijke Eend schreef:Als je de invoer 'live' op de server laat omzetten naar uitvoer, is het enige 'substantiële' dat je hebt niet-standaard invoer (bijvoorbeeld een MySQL-database met zelfbedachte structuur of tekstbestanden met een ingewikkelde DVEGEN-syntax) die over vijftig jaar misschien niet meer zomaar leesbaar is.
Daniel73 schreef:Mijn voorkeur gaat uit naar een manier waarop bezoekers (waaronder ikzelf) invoer-bestanden kunnen opladen naar de server. Mijn doel is dat zowel invoer als uitvoer beide online komen te staan. Als er dan een methode ontwikkeld kan worden om de uitvoer (bestaande uit vele HTML-bestanden) online op de server te laten genereren, zou dat veel tijd en moeite schelen bij het updaten.
Daniel73 schreef:Groot nadeel is nu dat het opladen van al gauw 1001 HTML-pagina's (bij Barks en Nijgh) een hele onderneming wordt, die bovendien tijd vreet. Dat ontmoedigt updaten, en dat terwijl het programma juist zo handig is om regelmatig gegevens te verversen.
Snelbinder schreef:Daniel73 schreef:Het programma is helaas nog in wording. Onvoltooid dus.
Aan de ene kant werkt het programma al jaren naar tevredenheid, voor mijn eigen websites.
Aan de andere kant is zo'n programma nooit af. Er zijn altijd wel bugs en extra wensen.
Snelbinder schreef:Daniel73 schreef:Ook vraag ik me af hoe het programma om zou kunnen gaan met php, style sheets, java-scripts, active scripts, etc.
Style sheets en javascript is geen probleem.
Voor PHP en dergelijke (ik neem aan dat je met "active scripts" dingen bedoelt als ASP en JSP) heb je een programma op de server nodig (bijvoorbeeld Tomcat). Het hangt dus van je provider af of zo'n programma beschikbaar is.
Snelbinder schreef:Daniel73 schreef:Mijn voorkeur gaat uit naar een manier waarop bezoekers (waaronder ikzelf) invoer-bestanden kunnen opladen naar de server. Mijn doel is dat zowel invoer als uitvoer beide online komen te staan. Als er dan een methode ontwikkeld kan worden om de uitvoer (bestaande uit vele HTML-bestanden) online op de server te laten genereren, zou dat veel tijd en moeite schelen bij het updaten.
Zowel voor het uploaden als voor het automatisch draaien van DveGen heb je de medewerking van je provider nodig.
Snelbinder schreef:Daniel73 schreef:Groot nadeel is nu dat het opladen van al gauw 1001 HTML-pagina's (bij Barks en Nijgh) een hele onderneming wordt, die bovendien tijd vreet. Dat ontmoedigt updaten, en dat terwijl het programma juist zo handig is om regelmatig gegevens te verversen.
Ik heb een website die ik wekelijks update. Hij bestaat uit bijna 600 pagina's. Maar omdat DveGen bijhoudt welke pagina's er veranderd zijn, hoef ik vaak niet meer dan 20 files te ftp-en.
Daniel73 schreef:Extra wensen houd ik nog maar even voor me, om de Tovervisjes niet al te veel te belasten.
Daniel73 schreef:in praktijk zijn er nog problemen. Zoals bij het gebruik van meerdere directories en plaatjes.
Daniel73 schreef:Verder is er geen mogelijkheid om de input, die bij uitgebreide sites gauw groot wordt, te re-structureren.
Daniel73 schreef:Jouw websites zijn relatief beknopt en vergen dus weinig van het programma.
Daniel73 schreef:Ik neem aan dat de uitvoer in een enkele directory past, zonder storend groot te zijn. Hoeveel pagina's telt elke site?
Daniel73 schreef:Stel je voor dat elke publicatie een eigen pagina zou krijgen
Snelbinder schreef:Zowel voor het uploaden als voor het automatisch draaien van DveGen heb je de medewerking van je provider nodig.
Daniel73 schreef:Ook hier zal ik navraag naar doen.
Zijn dit goede vragen?
- Is het mogelijk om bezoekers via een aparte directory te laten ftp-en, op een veilige manier?
- Is het mogelijk om een PHP-website te hebben?
- Is het mogelijk om een eigen programma op de server te draaien?
- Gaat het draaien van programma's van het toegestane dataverbruik af?
Snelbinder schreef:Ik heb een website die ik wekelijks update. Hij bestaat uit bijna 600 pagina's. Maar omdat DveGen bijhoudt welke pagina's er veranderd zijn, hoef ik vaak niet meer dan 20 files te ftp-en.
Daniel73 schreef:Hoe werkt dat met meerdere directories?
Snelbinder schreef:Ha! Een site van 600 pagina's is pinda's. Dan zou ik nu al klaar zijn.
Snelbinder schreef:[altijd zichtbare navigatiebalk]
Dit heb ik zojuist geprobeerd, en bij mij werkt het niet!
(Ik zie een gele navigatiebalk bovenaan, die verdwijnt bij het naar beneden scrollen.)
Snelbinder schreef:Daniel73 schreef:- Is het mogelijk om een PHP-website te hebben? [...]
Bij de vraag over PHP kan het ook handig zijn om MySQL te hebben.
Lelijke Eend schreef:Freerider biedt PHP 4-ondersteuning en je kunt zoveel MySQL-databases gebruiken als je wilt. PunBB werkt ook met PHP en MySQL.
Keer terug naar Computers en internet
Gebruikers op dit forum: Geen geregistreerde gebruikers. en 3 gasten