Project "DveGen" - database generator

Hardware, software, internetsites

Berichtdoor Daniel73 » vr apr 06, 2007 2:53 am

Dit topic gaat over een software-programma in wording, dat als werktitel 'DveGen' heeft. De werktitel is een woordspeling van de programmeur, door van mijn initialen (roepnaam/achternaam) een afkorting te maken voor "Database Values and Expressions GENerator". Wat de uiteindelijke titel zou kunnen zijn staat nog ter discussie.

Het programma is een methode om een "content management system" op te zetten dat kan samenwerken met een database-systeem zoals dat van Inducks.
Tot dusver bestaat de samenwerking aan het project uit twee personen. Ik en een programmeur. Ik lever wensen en de programmeur voert ze vaak uit. Dat lijkt een sprookje, met oneindig veel vervulde wensen. Maar een nadeel is echter wel dat er vooralsnog geen andere programmeur of gebruiker is die weet hoe het programma werkt (bv. welke taal) en hoe ermee om te gaan. En dat terwijl het programma mogelijkheden kan bieden voor velen. Zo is er op zich al weinig voor nodig om er als gebruiker een eenvoudige, kaartenbak-gebaseerde site mee op te zetten, waarbij een simpel kladblok/notepad-programma al kan voldoen.

Het programma is helaas nog in wording. Onvoltooid dus.
Bij een redelijk uitgebreide site zijn er nog wat haken en ogen, qua invoerbeheer en uitvoerbeheer. Ook is het vooralsnog lastig om met meerdere directories te werken, vanwege de moeilijkheidsgraad hoe plaatjes dan nog vindbaar kunnen zijn (welke directory) en hoe de direcories kan kunnen worden ingesteld.
Ook op het gebied van website-layout (uitvoer) zijn er nog beperkingen door onder meer een gebrek aan een mogelijkheid om "frames" te gebruiken. 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.
Verder zijn er daarbij een aantal wensen die wat mij betreft zowel de invoer als de uitvoer een technische vooruitgang op zich zouden maken in digitale archivering. Maar daarbij speelt momenteel het grote nadeel op dat afhankelijkheid van een enkele programmeur beperkingen geeft. Al was het maar vanwege gebrek aan tijd.
Hopelijk is dit topic een goede mogelijkheid om de voortgang van het programma in het openbaar te bespreken, op een "open source"-manier, om ook anderen te interesseren. Zowel programmeurs als gebruikers.

Veelbelovend aan programma vind ik dat het, in uitgebreide vorm, voor researchers interessante mogelijkheden biedt/belooft om informatie in te voeren en door het programma te laten combineren tot onverwachte ontdekkingen, die vervolgens op internet geplaatst kunnen worden in de vorm van een website.

Er zijn een aantal internet-sites die door het programma zijn genegereerd. Variërend van redelijk eenvoudig naar uitgebreid:

Uitlegsite van DveGen
http://bolderbast.inducks.org/dvegen/

DD50
http://dd50.inducks.org/

Bolderbast
http://bolderbast.inducks.org/

A Guidebook to the Carl Barks Universe (test)
http://www.seriesam.com/barks/

De Lennaert Nijgh Website (test)
http://www.tobia.nl/
http://www.lennaertnijgh.nl/

In principe moeten relatief eenvoudige sites, zoals de eerste drie, geen probleem zijn. Ze hebben een enkele directory en een relatief beknopte inhoud.
De laatste twee (Barks en Nijgh) zijn vooralsnog testen van wat het programma zoal aan geadvanceerde mogelijkheden kan bieden.

Zo is er bij Barks een aanzet tot een tijdlijn te zien, waarin door datums/jaren uit Barks's leven gewandeld kan worden.
http://www.seriesam.com/barks/diary.html
1 oktober 1960: http://www.seriesam.com/barks/diary1960.html#dry1960-10-01
Alleen de jaren 1960, 1961 en 1962 staan opgesomd, maar ze geven alvast een indruk van hoe diverse datums uit diverse velden gecombineerd kunnen worden tot een overzicht dat een kalender-/dagboek-achtige indruk geeft.

Bij de Nijgh-site is een poging ondernomen om behalve txt-bestanden ook binairy-bestanden (zoals plaatjes) te beheren. Vooralsnog een probleem, omdat het programma die zelf nog niet "ziet".

De Barks- en Nijgh-site zijn een voorbeeld voor elkaar. De ene "leert" van de ander. Tot dusver is de invoer voor Barks nog relatief eenvoudig. Bij Nijgh wordt intensief gebruik gemaakt van lijsten die automatisch samengesteld kunnen worden uit diverse invoer-velden. Zodoende zijn er bij Nijgh een aantal interessante doch database-technische moeilijke problemen, waarbij de invoer te gecompliceerd kan worden voor gebruikers.

Op de McDrake-server hoop ik met het programma een voorzichtige aanzet te maken tot een McDrake-bibliotheek/museum in testvorm. Dit biedt voor mij een mogelijkheid om een site vanaf de basis op te bouwen, en te testen in hoeverre het programma zou kunnen gebruikt worden in samenwerking met anderen. Van zo'n test kan ik met Barks en Nijgh profijt hebben, en andersom met McDrake.
Op die manier zou de McDrake-server dus dienen als een test-platform. Ik zal de McDrake-provider vragen naar eventuele mogelijkheden om veilig specifieke directories op McDrake open te stellen voor anderen dan alleen mijzelf. Nadeel is dat ik zelf weinig ervaring heb met servers, dus dat kan beperkingen geven.

Dit bericht is een introductie in vogelvlucht. Ik zal in komende berichten gaan proberen een enigszins coherente lijsten van voordelen en nadelen te maken, en voorbeelden te geven van hoe het programma werkt.
Daniel73
Member
 
Berichten: 917
Geregistreerd: vr jun 02, 2006 5:45 pm
Woonplaats: Nederland

Berichtdoor Lelijke Eend » vr apr 06, 2007 1:57 pm

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.

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.

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.

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.

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.
Lelijke Eend
New member
 
Berichten: 6
Geregistreerd: vr apr 06, 2007 1:22 pm

Berichtdoor Daniel73 » vr apr 06, 2007 4:16 pm

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.

Die "volgende/vorige"-links worden automatisch gegenereerd in HTML.
In principe is alles in te stellen, op wat haken en ogen na. Als auteur heb je veel controle, maar het gevaar bestaat dat de invoer dan dusdanig uniek wordt, dat exporteren naar andere database/cms-programma's lastig kan zijn.
DveGEN zou inmiddels een exportfunctie naar XML hebben, maar daar heb ik nog niet mee geëxperimenteerd. (Noch met exporteren, noch met XML.)

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.

Het programma werkt juist goed met eenvoudige sites, en het voordeel is dat je daarna altijd nog kunt beslissen in welk formaat je verder gaat. Voor het maken van pakweg vijf gekoppelde html-pagina's is het programma al handig, omdat je de HTML-layout in een enkel "definition"-bestand zet. Als je bijvoorbeeld de pagina's in een keer van achtergrondkleur wilt gaan veranderen, kan dat door een enkele aanpassing in dat "def"-bestand.

Met een McDrake-bibliotheek kan vanaf ik de grond een DveGEN-site maken. Zowel bij Barks als bij Nijgh bestaat de invoer uit omgezette HTML-pagina's. Daar moet nog veel opgeschoond worden. Zodoende zijn de invoerbestanden vooralsnog een rommeltje en lijkt het mij beter om met een nieuwe voorbeeldsite te beginnen. Mislukt het, dan kan de data altijd nog omgezet worden naar een ander formaat.
Men wil een bibliotheek en ik wil een bibliotheek. Ik wil deze opzetten als een experiment waarbij het publiek nauw betrokken kan zijn. Bij Barks en Nijgh wil ik ook op zo'n manier kunnen samenwerken met anderen, dus zo kan ik "from scratch" uittesten of en hoe dat gaat lukken.
Ik ben bijvoorbeeld benieuwd in hoeverre mensen aan te moedigen zijn om een beetje computertaal te leren, zoals met de BBCodes in PunBB. Als mensen BBCodes begrijpen en kunnen toepassen, dan kunnen ze al een heel eind komen. (HTML lijkt veel BBCode.)

De McDrake-bibliotheek zou te koppelen kunnen zijn aan PunBB, omdat PunBB gebruikt maakt van vaste topic-adressen. Een "reageer hier"-link moet dus vrij eenvoudig in te voeren zijn. DveGEN maakt volgt mij ook louter vaste adressen, die in te stellen zijn. Bij Barks en Nijgh hoop ik sowieso heen en weer te gaan koppelen met McDrake-boards. Ter vervanging van de email-links, die flessenhals-problemen geven.
Verder hoop ik dat de invoer van DveGEN kan samenwerken met een stem-systeem, zoals dat van McPrul. Ik ben benieuwd of er mogelijkheden kunnen zijn om invoer van DveGEN te gebruiken als invoer voor statistieken. Zo kan men automatisch zien hoeveel pagina's Barks per jaar maakte, en wat volgens bezoekers de meest/minst favoriete verhalen zijn.

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.

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?

Nadeel van het programma is vooralsnog dat de uitvoer leunt op HTML. Waarbij sommige ingebakken opties zelfs onvermijdelijk in HTML zijn. Misschien zijn er meer mogelijkheden als dit HTML-only principe losgelaten wordt.
Ook vraag ik me af hoe het programma om zou kunnen gaan met php, style sheets, java-scripts, active scripts, etc.

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.

Mijn voorkeur gaat uit naar vaste pagina's die over vijftig jaar nog steeds leesbaar zijn, zowel offline als online.

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.

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.
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.

Basis moet wat mij betreft wel zijn dat gebruikers altijd van DveGEN kunnen overstappen naar andere programma's. En hopelijk ook andersom, van andere programma's naar DveGEN.
Daniel73
Member
 
Berichten: 917
Geregistreerd: vr jun 02, 2006 5:45 pm
Woonplaats: Nederland

Berichtdoor Lelijke Eend » vr apr 06, 2007 5:52 pm

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?

Frames zijn eerder uitgeburgerd. De nadelen zijn te groot, vooral wat betreft het linken naar een specifieke pagina. Terwijl dat juist handig is bij een site met een hoop verschillende pagina's.

Als je een altijd zichtbare navigatiebalk wilt, kun je dat bijvoorbeeld met style sheets bereiken. Probeer de volgende HTML-code eens:
Code: Selecteer alles
<!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.

Style sheets moeten te doen zijn. Dat is gewoon een kwestie van een <link>- of een <style>-tag bovenaan de HTML-pagina's zetten. JavaScript heb je niet nodig en zou de site alleen maar ontoegankelijk maken: in browsers zonder JavaScript zouden dingen dan niet werken.
Lelijke Eend
New member
 
Berichten: 6
Geregistreerd: vr apr 06, 2007 1:22 pm

Berichtdoor Daniel73 » za apr 07, 2007 12:09 am

Hieronder uit het hoofd een simpel voorbeeld van input, layout-definitie en output:

- - - - - - - - - -

INPUT, te schrijven door gebruiker ("Jans Allemans"):

#code 0001
#category Auteurs
#title Biografie Floyd Barks
#schrijver Jans Allemans
#samenvatting
Beschrijving van het leven van Floyd Barks, Disneytekenaar van Knabbel en Babbel.
#inhoud
Floyd Barks werd geboren bla bla en toen bla bla en ook bla bla niet te vergeten bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla en toen bla bla bla bla bla bla bla bla.<BR>
Daarna bla bla en toen bla bla en ook bla bla niet te vergeten bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla en toen bla bla bla bla en ook bla bla bla.

- - - - - - - - - -

LAYOUT DEFINITIE, in te stellen door beheer (in een DEFinitie-bestand):

#categorie
%val
#title
<H3><U>%val</U></H3>
#schrijver
Geschreven door: <I>%val</I>
<P>
#samenvatting
<B>%val</B>
#inhoud
%val

- - - - - - - - - -

OUTPUT, zoals bezoekers het (ongeveer) zien:

Auteurs

Biografie Floyd Barks

Geschreven door: Jans Allemans

Beschrijving van het leven van Floyd Barks, Disneytekenaar van Knabbel en Babbel.

Floyd Barks werd geboren bla bla en toen bla bla en ook bla bla niet te vergeten bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla en toen bla bla bla bla bla bla bla bla.
Daarna bla bla en toen bla bla en ook bla bla niet te vergeten bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla en toen bla bla bla bla en ook bla bla bla.

- - - - - - - - - -

De code 0001 kan staan voor de naam van de HTML-pagina. ("0001.html") maar dat is een detail.

Door namen van tekstbestanden apart toe te wijzen aan gebruikers/schrijvers, zou elk een eigen afdeling kunnen krijgen in de gedroomde bibliotheek. Men kan dan zelf invoer bijhouden en uploaden:
- db_allemans_jans.txt (data van Jans Allemans)
- db_pietje.txt (data van Pietje)
(etc.)
Zo zou elk tekstbestand een account/profiel kunnen zijn. Maar zelfs al zou dat mogelijk zijn met DveGEN, dan komt hier nog veel bij kijken.

Waar ik op uit ben is een soort van 'Textpattern'-idee, zoals op McDuck. Daar had elke gebruiker/schrijver een eigen afdeling. Nadeel was dat kopij er vrijuit en willekeurig aangepast kon worden, wat vandalisme-gevoelig is. Om dat te ondervangen zou een CVS-systeem nodig zijn, dat veranderingen logt. Maar dat schijnt best moeilijk te zijn, zo'n logsysteem.


Hieronder een voorbeeld van input voor 'A Guidebook', uit tekstbestand "dbstories.txt".
Regels die beginnen met een uitroepen zijn onzichtbaar voor het programma en worden bij het genereren overgeslagen.


- - - - - - - - - -

INVOER:

! DBSTORIES.TXT
!
! Dit is een voorbeeld van een file met items. De "echte data" dus.
!
! Een item begint met #code met de key. Op de daarop volgende regels
! staan de velden van het item. De naam van een veld staat direct
! achter het #, de inhoud van het veld staat daar weer achter, en
! eventueel gaat het door op de volgende regel(s).
!
! Een veld mag ook %-opdrachten bevatten, zoals %link. Zie de uitleg
! in DBSTORIES.DEF.
!
! Bijzondere veldnamen zijn:
!
! #code: deze geeft aan dat hier een nieuw item begint. De code is
! de identificatie van het item
! #code moet altijd op 1 regel staan, en kan geen % bevatten.
! #inducks: de bijbehorende code in (een van de) Inducks-tabellen. Deze
! hoeft NIET hetzelfde te zijn als de #code!
!
! De overige veldnamen moeten vermeld zijn in de definitie-file die
! bij deze database-file hoort.
!
! De Inducks-velden (bijvoorbeeld "title", "pages") worden hier dus
! NIET genoemd: deze komen uit de Inducks-files!
! Alleen de eigen velden komen hier.
!
! Let op: als je een % wil gebruiken, zet er dan 2 neer: %%
!
!===========================================================================
#code ccus_dd0026-00
#mystoriesdesc real witch at door
#inducks W DD 26-00
#barrier MBAC-113
#cbl 02C-463; 02C front cover
#type cover, illustrating «%namedlink(ccus_dd0026-02,default,mystoriestitle)»
#artist Carl Barks
#writer [unknown]
#mystorieshero Donald Duck
#submissiondate 1952, April 10
#publicationdate %field(bbus_cm_dd0026,publicationdate)
#-subrecord s_issuelink
#-x_issuelink bbus_cm_dd0026
#mystoriespages 1
!
#toedoe
barrier vermeldt niet dat cover het hoofdverhaal illustreert
!
#additionalcredits
Front cover.
!
#credits
Information taken from Michael Barrier book "Carl Barks and the Art of the
Comic Book", <NOBR>page %field(%self,barrier).</NOBR>
!
!---------------------------------------------------------------------------
#code ccus_dd0026-01
#mystoriesdesc buggy on roof
#inducks W DD 26-01
#barrier MBAC-113
#cbl 02C-514
#type gag
#artist Carl Barks
#writer Carl Barks
#mystorieshero Donald Duck
#submissiondate 1952, April 10
#publicationdate %field(bbus_cm_dd0026,publicationdate)
#-subrecord s_issuelink
#-x_issuelink bbus_cm_dd0026
#mystoriespages 1
!
#toedoe
- ovek: halloween (Jet Witch)
- opmerkelijk: man heet "Gypo" (Gypo's Antique Shop)
!
#credits
Information taken from Michael Barrier book "Carl Barks and the Art of the
Comic Book", <NOBR>page %field(%self,barrier).</NOBR>
!
!---------------------------------------------------------------------------

- - - - - - - - - -

UITVOER:
http://www.seriesam.com/barks/comicsdd0026.html#ccus_dd0026-00
http://www.seriesam.com/barks/comicsdd0026.html#ccus_dd0026-01
Daniel73
Member
 
Berichten: 917
Geregistreerd: vr jun 02, 2006 5:45 pm
Woonplaats: Nederland

Berichtdoor Snelbinder » di apr 10, 2007 2:15 pm

Kwaak! Mijn eerste bericht op McDrake.nl.

Daniel73 schreef:Tot dusver bestaat de samenwerking aan het project uit twee personen. Ik en een programmeur.

En die programmeur ben ik dus. Harry. :)

Daniel73 schreef:Het programma is helaas nog in wording. Onvoltooid dus.

Dat is maar hoe je het bekijkt.
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.

Daniel73 schreef:Uitlegsite van DveGen
http://bolderbast.inducks.org/dvegen/

Deze site is een nogal droge opsomming van de mogelijkheden, zonder inleidende tekst.
Hij is geschikt voor mensen die het programma al kennen en nog even precies willen weten hoe het zit.

Ik heb ook een inleidende tekst, in powerpoint-vorm. Een dezer dagen wil ik die hier posten.
--Harry Snelbinder.
Snelbinder
Member
 
Berichten: 65
Geregistreerd: di apr 10, 2007 1:59 pm

Berichtdoor Snelbinder » di apr 10, 2007 3:23 pm

De uitleg waar ik het net over had.
Bij deze sheets hoort eigenlijk een verhaaltje, maar dat heb ik niet meer...

Afbeelding
Afbeelding
Afbeelding
Afbeelding
Afbeelding
Afbeelding
Afbeelding
Afbeelding
Afbeelding
Afbeelding
Afbeelding
Afbeelding
Afbeelding
--Harry Snelbinder.
Snelbinder
Member
 
Berichten: 65
Geregistreerd: di apr 10, 2007 1:59 pm

Berichtdoor Snelbinder » di apr 10, 2007 3:29 pm

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.

Dit heb ik zojuist geprobeerd, en bij mij werkt het niet!
(Ik zie een gele navigatiebalk bovenaan, die verdwijnt bij het naar beneden scrollen.)
--Harry Snelbinder.
Snelbinder
Member
 
Berichten: 65
Geregistreerd: di apr 10, 2007 1:59 pm

Berichtdoor Snelbinder » di apr 10, 2007 3:48 pm

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.

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.

Voordeel van DveGen-input is wel dat het gewone tekst-bestanden zijn. Die zullen toch wel in lengte van dagen leesbaar blijven. Alleen de structuur (de #s en %s) is specifiek voor DveGen, maar volgens mij niet moeilijk te begrijpen.

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.

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.
--Harry Snelbinder.
Snelbinder
Member
 
Berichten: 65
Geregistreerd: di apr 10, 2007 1:59 pm

Berichtdoor Daniel73 » di apr 17, 2007 2:07 am

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.

Als content management system zijn er nog haken en ogen. Bij sites als die over Barks en Nijgh zijn er nog problemen waarin het programma bij mijn weten geen oplossing biedt.
Dat gaat dus om data-modellen en staat dus nog los van bugs en extra wensen. Bugs zou ik nu zo gauw niet weten te noemen. Extra wensen houd ik nog maar even voor me, om de Tovervisjes niet al te veel te belasten. :)

De kracht van het programma is dat het grote hoeveelheden informatie kan verwerken. Maar in praktijk zijn er nog problemen. Zoals bij het gebruik van meerdere directories en plaatjes. Verder is er geen mogelijkheid om de input, die bij uitgebreide sites gauw groot wordt, te re-structureren.

A Guidebook to the Carl Barks Universe (test)
http://www.seriesam.com/barks/
De Lennaert Nijgh Website (test)
http://www.tobia.nl/
http://www.lennaertnijgh.nl/

Jouw websites zijn relatief beknopt en vergen dus weinig van het programma. Daarvoor is het programma wel geschikt. Ik neem aan dat de uitvoer in een enkele directory past, zonder storend groot te zijn. Hoeveel pagina's telt elke site?

Uitlegsite van DveGen
http://bolderbast.inducks.org/dvegen/
DD50
http://dd50.inducks.org/
Bolderbast
http://bolderbast.inducks.org/

Zodra je, bijvoorbeeld, een site zou maken over alle Nederlandse Disney-strips, met zodoende duizenden publicaties en hun inhoud, dan wordt het lastig. Stel je voor dat elke publicatie een eigen pagina zou krijgen, dan heb je al ruim 2000 pagina's voor Donald Duck weekblad alleen. En als ik van elke publicatie een scan wil laten zien, heb ik voor die plaatjes al een of meer aparte directories nodig.

Bij Nijgh en bij Barks, die elk honderden, wijdverbreid gepubliceerd werken op hun naam hebben staan, daar ben ik zodoende veel problemen tegengekomen.
Hun werk en leven zorgt voor monsterlijke data-proporties. Er zijn veel van de problemen opgelost, maar bij mijn weten niet alles.

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.

Dat zal ik na moeten vragen.

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.

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:
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.

Hoe werkt dat met meerdere directories?
Ha! Een site van 600 pagina's is pinda's. Dan zou ik nu al klaar zijn. :)
Daniel73
Member
 
Berichten: 917
Geregistreerd: vr jun 02, 2006 5:45 pm
Woonplaats: Nederland

Berichtdoor Snelbinder » di apr 17, 2007 1:24 pm

Uhm... test
--Harry Snelbinder.
Snelbinder
Member
 
Berichten: 65
Geregistreerd: di apr 10, 2007 1:59 pm

Berichtdoor Snelbinder » di apr 17, 2007 2:16 pm

Daniel73 schreef:Extra wensen houd ik nog maar even voor me, om de Tovervisjes niet al te veel te belasten. :)

Ik hoop dat de extra wensen niet zodanig groot zijn dat Dvegen 2 keer zo groot zou moeten worden.

Daniel73 schreef:in praktijk zijn er nog problemen. Zoals bij het gebruik van meerdere directories en plaatjes.

Als je alle plaatjes een absoluut pad geeft (dus niet relatief aan de pagina), heb je daar geen problemen. Alleen dan wordt off-line testen wel weer lastig (want je kunt niet bij de plaatjes als je off-line bent).
Maar daar valt wel een oplossing voor te bedenken.

Daniel73 schreef:Verder is er geen mogelijkheid om de input, die bij uitgebreide sites gauw groot wordt, te re-structureren.

Hoe zou je dat opgelost zien? Een optie in Dvegen om de input-files opnieuw te schrijven?
Dat lijkt me behoorlijk lastig, want bij het inlezen van de input slaat Dvegen bijvoorbeeld commentaar-regels over. Die zou je in gestructureerde input dan niet meer terugzien.

Daniel73 schreef:Jouw websites zijn relatief beknopt en vergen dus weinig van het programma.

Ik denk dat mijn wegensite niet zo beknopt meer is. Maar het "datamodel" erachter is inderdaad een stuk simpeler dan bij jouw Nijghsite.
(Hoewel ik soms zelf al de kluts kwijtraak bij mijn eigen datamodel.)

Daniel73 schreef:Ik neem aan dat de uitvoer in een enkele directory past, zonder storend groot te zijn. Hoeveel pagina's telt elke site?

Mijn wegensite bevat 600 pagina's. Maar daarop staan meer dan 3000 items. Dvegen heeft op mijn snelle PC een halve minuut nodig om alles te genereren.

Daniel73 schreef:Stel je voor dat elke publicatie een eigen pagina zou krijgen

Op mijn wegensite ben ik van dat principe afgestapt. Ik zet nu soms 10 tot 20 items op 1 pagina.
Niet alleen om het aantal files te verminderen (ftp is soms erg traag omdat het per file een verbinding moet opzetten).
Maar ook voor de lezer van de website. Die wil ik graag een balans aanbieden tussen redelijk kleine pagina's en redelijk weinig navigeren tussen pagina's.

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?

Bij de vraag over PHP kan het ook handig zijn om MySQL te hebben.
Maar dan slaan we wel een geheel nieuwe richting in: Dvegen zou de data via een SQL-script in MySQL in kunnen lezen. De PHP-files halen hun gegevens daar dan weer uit. (Je hebt dan wel iemand nodig die in PHP kan programmeren.)
Bij coa.inducks.org werken ze ook ongeveer op die manier.

Ik zit er sterk aan te denken dat dat wel een goede oplossing zou zijn. Voordeel is dat de halve wereld je kan helpen bij het PHP-en en SQL-en.

Die laatste vraag ("gaat het van het toegestane dataverbruik af") begrijp ik niet, dus misschien begrijpt een provider hem ook niet. :)

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?

Ik heb alles nog op 1 directory staan. Maar als ik me goed herinner werkt het ook als je diverse subdirectory's maakt.
(In het verleden heb ik dat wel eens met mijn wegensite gedaan. Het beviel me niet, omdat ik dan met mijn ftp-programma iedere directory afzonderlijk langs moest.)

Snelbinder schreef:Ha! Een site van 600 pagina's is pinda's. Dan zou ik nu al klaar zijn. :)

Volgens mijn gegevens heeft je Nijghsite ruim 8000 items. Mijn wegensite heeft er momenteel 3353. Dus ik ben al aardig op weg... :)
--Harry Snelbinder.
Snelbinder
Member
 
Berichten: 65
Geregistreerd: di apr 10, 2007 1:59 pm

Berichtdoor Lelijke Eend » di apr 17, 2007 7:34 pm

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.)

Zo te zien ondersteunen oude versies van Internet Explorer het niet...

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.

Freerider biedt PHP 4-ondersteuning en je kunt zoveel MySQL-databases gebruiken als je wilt. PunBB werkt ook met PHP en MySQL.
Lelijke Eend
New member
 
Berichten: 6
Geregistreerd: vr apr 06, 2007 1:22 pm

Berichtdoor Snelbinder » wo apr 18, 2007 9:40 am

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.

Zijn Freerider en PunBB providers?
--Harry Snelbinder.
Snelbinder
Member
 
Berichten: 65
Geregistreerd: di apr 10, 2007 1:59 pm

Berichtdoor Lelijke Eend » wo apr 18, 2007 10:01 am

Freerider is de provider van McDrake (zie het overzicht van wat aangeboden wordt), en PunBB is het PHP-programma dat voor dit forum gebruikt wordt. Ik had het inderdaad niet helemaal helder geformuleerd. :)
Lelijke Eend
New member
 
Berichten: 6
Geregistreerd: vr apr 06, 2007 1:22 pm

Volgende

Keer terug naar Computers en internet

Wie is er online

Gebruikers op dit forum: Geen geregistreerde gebruikers. en 4 gasten

cron