Project "DveGen" - database generator

[Snelbinder]

Zojuist een nieuwe feature ingebouwd in DveGen.

In de file DVEGEN.TXT kun je de volgende regel toevoegen:

images, c:directorypad

Dit geeft aan welke directory's op je harde schijf gebruikt worden voor images.
DveGen kan controleren of images (of eigenlijk ook andere files) echt bestaan.
En of er files in een van die directory's staan die niet op de webpagina's gebruikt worden.
Je moet dan wel bij ieder gebruik van een file de opdracht %checkusage gebruiken.

De directory moet op je harde schijf staan, want tijdens het draaien van DveGen is er misschien geen toegang tot internet.
Alle subdirectory's van deze directory worden ook meegenomen.

Je zult dus zelf met een ftp-programma moeten controleren of de files op je harde schijf overeenkomen met die op de webserver.

Voorbeeld van gebruik van %checkusage in een DEF-file:

#img
<img src="img/%val.jpg">
%checkusage(%val,jpg)

Dus overal waar je een IMG-tag hebt staan kun je een %checkusage toevoegen. DveGen scant zelf niet op die IMG-tag.

Ik ben zelf nog aan het testen, maar volgens mij werkt het vrij aardig.

Deze nieuwe feature werkt trouwens alleen als je DveGen op een Windows-machine draait...

[Snelbinder]

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.

Ik begrijp niet helemaal welke kant je hier op wil, maar ik heb even nagezocht welke HTML-code is ingebakken in het programma.
Het gaat om:

<a name=...>...</a>
<a href=....>...</a>
<b>Dve<i>Gen</i></b>
<PRE>..</PRE> (in een optie die ik alleen zelf gebruik)

Aangezien DveGen zelf hyperlinks maakt, zie ik niet zo gauw wat er in plaats van deze HTML zou moeten komen.

[Daniel73]

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.

Kan Dvegen werken met PHP? Wat zijn "active scripts"?

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.

Wat ik me voorstel is dat de input compatible is met meerdere output-formaten, zodat een site (output) op basis van dezelfde input op verschillende manieren kan worden aangesproken. Bijvoorbeeld als HTML-formaat én als PHP-formaat. Een ander voorbeeld is het aanbieden van printer-vriendelijke versies van HTML-pagina's die van tabel-layouts gebruik maken.

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.

Volgens mij gaat het vooral om verfijningen van wat er al is. Zeker als Dvegen met plaatjes om kan gaan.

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.

Wat ik zoek is, in de output, de relatieve manier hoe in HTML-taal (en DOS?) gelinkt kan worden naar subdirectories. ("../../tekst.txt") Die manier werkt zowel offline als online.

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.

Ja, een optie in Dvegen om de input-files opnieuw te schrijven.
Een oplossing voor de commentaar-regels is dat ook deze in structuur geplaatst worden.

Zou het verder mogelijk zijn om de "!" commentaar-regels dan aan te zetten, zodat ze bij genereren van input naar input wel door Dvegen gezien worden? Dat zou tenminste de mogelijkheid geven om elk tekstbestand een "!"-inleiding te geven en om lege "!"-regels aan te brengen tussen velden en items.

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

Met Barks en Nijgh hoop ik zover te gaan dat ik hun werk kan indelen met een verzen-systeem. Bij Barks kunnen dat de panel-nummers zijn. Dat zou bijvoorbeeld de mogelijkheid geven om de vergelijking van de Nederlandse 'Trick or Treat'-herdrukken te indexen.
http://www.seriesam.com/barks/deta_text_s_trick_treat_survey.html
Een ander voorbeeld is het in kaart brengen van herdrukverschillen in de CBL. Dat gaat vaak om pagina's en plaatjes. Daar kan ik nu niet bij. En ik ben bezig met een opsomming van namen, jaartallen en lokaties in verhalen, wat meestal gaat om plaatjes.

Bij Nijgh kan het handig zijn bij het vergelijken van tekstversies. Maar daar moet ik dan zelf een nummering voor bedenken. Bijvoorbeeld elk couplet en elke regel een nummer. ('Het land van Maas en Waal' 1:1, etc.)

Ik wil me gaan specialiseren in het vergelijken van versies en herdrukken. Het zou dan handig zijn om een vaste nummering te hebben. Zoals met de Bijbel. (Al zijn daar versnummer-verschillen in edities.)
Bij strips komt dit dus neer op het indexen van panels als kleinste eenheid, in plaats van hele verhalen. Ik wil niet alleen moleculen maar ook atomen kunnen indexen. Waar een ander dus ophoudt bij een zandkorrel, wil ik kunnen indexen waaruit die zandkorrel bestaat.

Vraag is hoe dat in een data-model past.

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.

Bij Nijgh wordt gebruik gemaakt van sub-records, geavanceerde automatische lijsten, en vele onderlinge heen-en-weer linken tussen items.
(Zover ben ik met Barks nog niet.)

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.

Ik zou beide mogelijkheden willen bieden. Losse pagina's en lijsten. Zoals er nu bovenaan pagina's een lijst staat van wat er verderop de pagina te vinden is. Ik vind dat bij zowel Barks en Nijgh nu te weinig overzicht is. Al was het maar omdat van het ene werk meer bekend is dan van het andere.
http://www.seriesam.com/barks/comicsos0009.html
http://www.tobia.nl/lnlt_ll.html

Nu gaat het me vooral om het structureren van de input. Uiteindelijk wil ik daarmee een effectieve output kunnen leveren. Bijvoorbeeld, bij Barks, lijsten van verhalen met veranderingen. Lijsten van verhalen die in bv. 1960 zijn verschenen. Etc.

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?

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.

Wat ik mooi zou vinden is dat het in elk geval mogelijk is om een nieuwe richting in te slaan, maar dan het liefst wel met behoud van mogelijkheden van oude richtingen. Zodat ik ondertussen kan blijven doorwerken met bv. HTML-output, totdat iemand opstaat die aan een PHP-versie wil werken. Zonder dat ik daarvan afhankelijk wordt.

Dvegen zou zodoende dus, als content management system, content (input) aan kunnen bieden aan een ieder die er verder mee wil experimenteren.

Met de laatste vraag, over het toegestane dataverbruik, bedoel ik de data-hoeveelheid die DVegen nodig heeft als werkgeheugen. Ik neem dat dergelijke data geparkeerd moet worden op bv. een schijf, die van de provider in dit geval. Ik vraag me af hoeveel extra zoiets kan gaan kosten. Het lijkt me stug dat ik zomaar een loodzware Dvegen kan gaan draaien, zonder bijbetaling.
Hoe kan ik dat in een vraag verwoorden, die de provider wel zal begrijpen?

[meerdere output-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.)

Dat is dus het volgende probleem. Hoe kan ik meerdere directories updaten via ftp? Misschien kan een ftp-programma ingesteld worden op verschil in datum?
Als ik meerdere directories in een keer kan updaten zonder dat ik steeds alles opnieuw moet uploaden, is het makkelijk om grote sites (met veel directories) regelmatig te updaten.

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

Wacht maar tot ik die 8000 zandkorrels heb opgesplitst in atomen.

Zojuist een nieuwe feature ingebouwd in DveGen.

In de file DVEGEN.TXT kun je de volgende regel toevoegen:

images, c:directorypad

Dit geeft aan welke directory's op je harde schijf gebruikt worden voor images.
DveGen kan controleren of images (of eigenlijk ook andere files) echt bestaan.
En of er files in een van die directory's staan die niet op de webpagina's gebruikt worden.
Je moet dan wel bij ieder gebruik van een file de opdracht %checkusage gebruiken.

De directory moet op je harde schijf staan, want tijdens het draaien van DveGen is er misschien geen toegang tot internet.
Alle subdirectory's van deze directory worden ook meegenomen.

Je zult dus zelf met een ftp-programma moeten controleren of de files op je harde schijf overeenkomen met die op de webserver.

Bedankt voor de nieuwe feature.
Een reden waarom Dvegen niet via internet werkt is toch ook omdat er dan van protocollen (zoals http) gebruik gemaakt wordt? Heb ik dat goed onthouden van wat je me een keer vertelde?

Zijn er file compare programma's die lokale directories kunnen vergelijken met ftp-directories?

Voorbeeld van gebruik van %checkusage in een DEF-file:

#img
<img src="img/%val.jpg">
%checkusage(%val,jpg)

Dus overal waar je een IMG-tag hebt staan kun je een %checkusage toevoegen. DveGen scant zelf niet op die IMG-tag.

Ik ben zelf nog aan het testen, maar volgens mij werkt het vrij aardig.

Deze nieuwe feature werkt trouwens alleen als je DveGen op een Windows-machine draait...

Momenteel heb ik nog problemen met mijn nieuwe computer. De computerwinkel heeft het systeem gewist en opnieuw geïnstalleerd. En er is een video-kaart in de reparatie. Mijn data is wel behouden, geparkeerd op een schijf, maar programma's (zoals ftp) ontbreken. Elke keer als ik mijn computer wegbreng krijg ik er een probleem bij. Het een en ander levert dus vertragingen op. :/

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.

Ik begrijp niet helemaal welke kant je hier op wil, maar ik heb even nagezocht welke HTML-code is ingebakken in het programma.
Het gaat om:

<a name=...>...</a>
<a href=....>...</a>
<b>Dve<i>Gen</i></b>
<PRE>..</PRE> (in een optie die ik alleen zelf gebruik)

Aangezien DveGen zelf hyperlinks maakt, zie ik niet zo gauw wat er in plaats van deze HTML zou moeten komen.

Kunnen formaten als MySQL, PHP, etc., daarmee omgaan, met ingevakken HTML-codes?

[Snelbinder]

Kan Dvegen werken met PHP?

Dvegen kan PHP-files genereren. Maar het is de vraag of je dat moet willen. PHP is in feite de dynamische variant van Dvegen (een vervanging van de DEF-files).
PHP is niet een "formaat". Het is een taaltje om HTML te genereren.

Wat zijn "active scripts"?

Geen idee.
Jij kwam met die kreet. Ik probeerde alleen te interpreteren wat je ermee zou kunnen bedoelen.

Wat ik zoek is, in de output, de relatieve manier hoe in HTML-taal (en DOS?) gelinkt kan worden naar subdirectories. ("../../tekst.txt") Die manier werkt zowel offline als online.

Ja. Relatieve links werken alleen als je kunt voorspellen in welke subdirectory de HTML komt te staan.
Het werkt dus als je ALLE outputfiles in een subdirectory zet (hoeft niet voor allemaal dezelfde te zijn). Dan wijst bijvoorbeeld "../img/blabla.jpg" altijd naar de goede directory.
Het gaat pas fout als sommige outputfiles in een subdirectory staan en andere niet. Dan kun je niet zomaar "../img/blabla.jpg" gebruiken, omdat dat dan soms naar de verkeerde directory wijst.
Dit is trouwens het enige probleem dat er nog is met subdirectory's.
In jouw geval wil je (denk ik) de "index.html" in de hoofddirectory hebben staan en alle andere html-files in (diverse) subdirectory's.
Hiervoor kan ik 2 simpele oplossingen bedenken:
1. gebruik op index.html geen enkel plaatje (of hooguit plaatjes met een afwijkend pad);
2. maak een index.html die een "redirect" bevat naar "subdir/index.html".

Ja, een optie in Dvegen om de input-files opnieuw te schrijven.

Dat wordt een behoorlijke klus, ALS het al mogelijk is zonder Dvegen helemaal opnieuw te maken.

Ik wil niet alleen moleculen maar ook atomen kunnen indexen.

Zo heb je wel werk gecreëerd voor jezelf voor de komende 10 jaar.

Vraag is hoe dat in een data-model past.

Lijkt me niet zo moeilijk. Geef elke zandkorrel een unieke code en zet erbij bij welk verhaal/item het hoort.

Ik zou beide mogelijkheden willen bieden. Losse pagina's en lijsten.
Nu gaat het me vooral om het structureren van de input. Uiteindelijk wil ik daarmee een effectieve output kunnen leveren. Bijvoorbeeld, bij Barks, lijsten van verhalen met veranderingen. Lijsten van verhalen die in bv. 1960 zijn verschenen. Etc.

Als ik dit zo lees heb je echt iets dynamischers nodig dan Dvegen. Dus PHP (of JSP, ASP, enz.)

Wat ik mooi zou vinden is dat het in elk geval mogelijk is om een nieuwe richting in te slaan, maar dan het liefst wel met behoud van mogelijkheden van oude richtingen. Zodat ik ondertussen kan blijven doorwerken met bv. HTML-output, totdat iemand opstaat die aan een PHP-versie wil werken. Zonder dat ik daarvan afhankelijk wordt.

Dvegen zou zodoende dus, als content management system, content (input) aan kunnen bieden aan een ieder die er verder mee wil experimenteren.

Misschien zou het leuk zijn om Dvegen opnieuw te bouwen, maar dan in PHP of zo. Hoewel...

Met de laatste vraag, over het toegestane dataverbruik, bedoel ik de data-hoeveelheid die DVegen nodig heeft als werkgeheugen. Ik neem dat dergelijke data geparkeerd moet worden op bv. een schijf, die van de provider in dit geval.

Aha. Misschien laten providers het draaien van eigen programma's daarom wel helemaal niet toe, tenzij je een dedicated server hebt.
En zo'n dedicated server loopt nogal in de papieren.

Het lijkt me stug dat ik zomaar een loodzware Dvegen kan gaan draaien

Nou, dat "loodzwaar" valt ook wel weer mee. Bovendien zou je het maar 1 keer per etmaal draaien of zo.

[meerdere output-directories]

Nee, dat heb ik niet geschreven. Ik zou nooit directory's verkeerd spellen.

Dat is dus het volgende probleem. Hoe kan ik meerdere directories updaten via ftp? Misschien kan een ftp-programma ingesteld worden op verschil in datum?

Ikzelf gebruik Windows Commander (nieuwere versies heten Total Commander) voor het ftp'en. In dit programma kun je je lokale directory vergelijken met de directory op de server. (Maar subdirectory's moet je eerst zelf "binnengaan".)
De vergelijking gaat op datum. Dit werkt trouwens alleen als de klokken op beide machines (bijna) gelijk staan.

Een reden waarom Dvegen niet via internet werkt is toch ook omdat er dan van protocollen (zoals http) gebruik gemaakt wordt? Heb ik dat goed onthouden van wat je me een keer vertelde?

Het openen van een file op een PC vanaf harde schijf (of een schijf in je lokale netwerk) is een heel ander verhaal dan het openen van een file via internet.
Misschien is dat over een jaar of tien niet meer een probleem. Ik werk bijvoorbeeld op dit moment aan een systeem (prototype) om dat probleem op te lossen. (Maar dat is een heel ander onderwerp...)

Kunnen formaten als MySQL, PHP, etc., daarmee omgaan, met inge(b?)akken HTML-codes?

Het zijn geen "formaten".
MySQL is een databaseprogramma. Daarin kun je onder andere HTML opslaan.
PHP is een programmeertaal. Daarmee kun je onder andere HTML genereren.
Het antwoord zal dus wel "ja" zijn.

[Daniel73]

Kan Dvegen werken met PHP?

Dvegen kan PHP-files genereren. Maar het is de vraag of je dat moet willen. PHP is in feite de dynamische variant van Dvegen (een vervanging van de DEF-files).
PHP is niet een "formaat". Het is een taaltje om HTML te genereren.

Wat voor input-formaat heeft PHP nodig, als taaltje om HTML te genereren?

Wat zijn "active scripts"?

Geen idee.
Jij kwam met die kreet. Ik probeerde alleen te interpreteren wat je ermee zou kunnen bedoelen.

Je nam aan dat ik met "active scripts" dingen bedoel als ASP en JSP. Ik weet niet wat ASP en JSP zijn.

Wat ik zoek is, in de output, de relatieve manier hoe in HTML-taal (en DOS?) gelinkt kan worden naar subdirectories. ("../../tekst.txt") Die manier werkt zowel offline als online.

Ja. Relatieve links werken alleen als je kunt voorspellen in welke subdirectory de HTML komt te staan.
Het werkt dus als je ALLE outputfiles in een subdirectory zet (hoeft niet voor allemaal dezelfde te zijn). Dan wijst bijvoorbeeld "../img/blabla.jpg" altijd naar de goede directory.
Het gaat pas fout als sommige outputfiles in een subdirectory staan en andere niet. Dan kun je niet zomaar "../img/blabla.jpg" gebruiken, omdat dat dan soms naar de verkeerde directory wijst.
Dit is trouwens het enige probleem dat er nog is met subdirectory's.
In jouw geval wil je (denk ik) de "index.html" in de hoofddirectory hebben staan en alle andere html-files in (diverse) subdirectory's.
Hiervoor kan ik 2 simpele oplossingen bedenken:
1. gebruik op index.html geen enkel plaatje (of hooguit plaatjes met een afwijkend pad);
2. maak een index.html die een "redirect" bevat naar "subdir/index.html".

Bij de Nijgh-input ben ik bezig geweest om alle binaire bestanden (zoals plaatjes) te indexen. Daar kan ik een pad, directory, subdirectory neerzetten. Is dat een oplossing?

Ja, een optie in Dvegen om de input-files opnieuw te schrijven.

Dat wordt een behoorlijke klus, ALS het al mogelijk is zonder Dvegen helemaal opnieuw te maken.

Hoezo? Het gaat om een uiterst simpele manier van genereren. In een def-bestand kan worden vermeld hoe de uiteindelijke structuur moet zijn, en dan hoeft alleen de tekst in die volgorde gekopieerd te worden van het ene bestand naar het andere. Ik wil me niet al te technisch voordoen, maar dat zou met een macro toch al moeten kunnen?

Bijvoorbeeld, een chaotische input:
#code wdc001
#aantalpaginas 10
#titel Donald Duck als Donald Duck
#artiest Floyd Barks

Ik wil de velden in een andere volgorde:
1. #code
2. #artiest
3. #titel
4. #aantalpaginas

Dan stel ik me voor dat een programma (zoals Dvegen, of een macro?) de chaotische input kan kopiëren in de gewenste structuur.

Dus:
#code wdc001
#artiest Floyd Barks
#titel Donald Duck als Donald Duck
#aantalpaginas 10

Het enige wat het programma hoeft te doen is het negeren van %-opdrachten en "!"-commentaarregels. Zodat ook deze een-op-een worden gekopieerd van het ene, oude bestand (de chaotische input) naar het andere, nieuwe bestand (de gestructureerde input).

Door de input te kunnen sorteren ben ik niet steeds gebonden aan een volgorde-beslissing. Nu kom ik daarmee vaak vast te zitten omdat door onvermijdelijk voortschrijdend inzicht een andere velden-volgorde gewenster blijkt. Ook omdat de volgorde nu per item verschilt, door overhaaste volgorde-beslissingen die nu niet terug te draaien zijn. Dat heeft de input ontzettend chaotisch gemaakt.

Een probleem kan wel liggen in de zogenaamde subrecords. Maar daar had je volgens mij al een mogelijkheid voor, om die te benaderen en dus te identificeren als zijnde subrecords.

Ik wil niet alleen moleculen maar ook atomen kunnen indexen.

Zo heb je wel werk gecreëerd voor jezelf voor de komende 10 jaar.

Bij een aantal werken van met name Barks kan het handig zijn om er alvast mee te beginnen, als experiment.

Vraag is hoe dat in een data-model past.

Lijkt me niet zo moeilijk. Geef elke zandkorrel een unieke code en zet erbij bij welk verhaal/item het hoort.

Oke. Maar welke code en in welk formaat? De "stories" worden zodoende "issues" op zich. Dus hoe kan ik dan een code definiëren?

Bijvoorbeeld "wdc001-04-08-02"?
Dat zou panel 8.2 van het 4de verhaal van WDC 1 zijn.

Ik zou beide mogelijkheden willen bieden. Losse pagina's en lijsten.
Nu gaat het me vooral om het structureren van de input. Uiteindelijk wil ik daarmee een effectieve output kunnen leveren. Bijvoorbeeld, bij Barks, lijsten van verhalen met veranderingen. Lijsten van verhalen die in bv. 1960 zijn verschenen. Etc.

Als ik dit zo lees heb je echt iets dynamischers nodig dan Dvegen. Dus PHP (of JSP, ASP, enz.)

Waarom dynamischer? Ik kan het nu al. Zelf wil ik werken met een vast HTML-formaat. Maar als iemand anders er iets dynamischer van wil maken, dan wil ik input kunnen bieden die compatible is. Zoals er nu een vertaalslag is van Dvegen naar de Inducks database. Waar ik voor wil uitkijken is dat ik met mijn input in een doodlopende straat terecht kom. Als bijvoorbeeld iemand op basis van de Dvegen-input een dynamische site wil maken, wil ik ondertussen zelf parallel door kunnen blijven werken aan een vaste HTML-versie.

Met de input wil ik een database/cms-formaat vastleggen, waar op voort gebouwd kan worden. Daarom heb ik output (layout, etc.) voorlopig nog als een lagere prioriteit, omdat iedereen output moet kunnen maken.
De input is mijn feitelijke produkt. Die moet tijdsbestendig zijn.

Wat ik mooi zou vinden is dat het in elk geval mogelijk is om een nieuwe richting in te slaan, maar dan het liefst wel met behoud van mogelijkheden van oude richtingen. Zodat ik ondertussen kan blijven doorwerken met bv. HTML-output, totdat iemand opstaat die aan een PHP-versie wil werken. Zonder dat ik daarvan afhankelijk wordt.

Dvegen zou zodoende dus, als content management system, content (input) aan kunnen bieden aan een ieder die er verder mee wil experimenteren.

Misschien zou het leuk zijn om Dvegen opnieuw te bouwen, maar dan in PHP of zo. Hoewel...

Ik denk (hoop) dat het meer gaat om het vaststellen van een universele input-structuur. Dus dat de input opnieuw moet worden opgebouwd, of tenminste strak gedefinieerd.
Zodat Dvegen een van de mogelijkheden wordt om mee verder te experimenteren, maar niet perse de enige mogelijkheid. Als er een input is die door zowel Dvegen als door een ander programma (bv. MySQL) te interpreteren is, hetzij direct, hetzij via een vertaalslag, dan nodigt dat wellicht meer mensen uit om van de input gebruik te maken. De een in Dvegen en de ander in bv. PHP.

Met de laatste vraag, over het toegestane dataverbruik, bedoel ik de data-hoeveelheid die DVegen nodig heeft als werkgeheugen. Ik neem dat dergelijke data geparkeerd moet worden op bv. een schijf, die van de provider in dit geval.

Aha. Misschien laten providers het draaien van eigen programma's daarom wel helemaal niet toe, tenzij je een dedicated server hebt.
En zo'n dedicated server loopt nogal in de papieren.

Het lijkt me beter om dan eerst de input centraal te stellen. Als dat produkt goed is en "verkoopbaar", dan zou zo'n dedicated server er best weleens kunnen komen.
Nu heb ik met Barks nog te vaak het probleem dat ik vast kom te zitten en ik dus niet kan reageren op eventuele aanwijzingen van de server-beheerder. Wie weet wat een dergelijke beheerder anders nog te bieden kan hebben, als hij ziet welke mogelijkheden de input biedt.

[meerdere output-directories]

Nee, dat heb ik niet geschreven. Ik zou nooit directory's verkeerd spellen.

Hoezo is "directories" verkeerd gespeld? Het meervoud van Harry is toch Harries?

Voorbeeldzin: "Ik ben dol op mijn Harries, maar zoveel aandacht als ze na de Playboy-reportage hebben gehad, slaat echt alles." (Georgina Verbaan)

Dat is dus het volgende probleem. Hoe kan ik meerdere directories updaten via ftp? Misschien kan een ftp-programma ingesteld worden op verschil in datum?

Ikzelf gebruik Windows Commander (nieuwere versies heten Total Commander) voor het ftp'en. In dit programma kun je je lokale directory vergelijken met de directory op de server. (Maar subdirectory's moet je eerst zelf "binnengaan".)
De vergelijking gaat op datum. Dit werkt trouwens alleen als de klokken op beide machines (bijna) gelijk staan.

Ik ga op zoek.

Kunnen formaten als MySQL, PHP, etc., daarmee omgaan, met inge(b?)akken HTML-codes?

Het zijn geen "formaten".
MySQL is een databaseprogramma. Daarin kun je onder andere HTML opslaan.
PHP is een programmeertaal. Daarmee kun je onder andere HTML genereren.
Het antwoord zal dus wel "ja" zijn.

Hebben databaseprogramma MySQL en programmeertaal PHP andere methodes om te linken, naast die van HTML?

[Snelbinder]

Wat voor input-formaat heeft PHP nodig, als taaltje om HTML te genereren?

Dit soort dingen:

Code: Selecteer alles

<?php
include('header.php');

$colo1 = "#ffcc33";
$colo2 = "#cbdced";

if ($c2) {
  echo "<table border=0>";
  $nom = $c2;

  $charactercodeArray = util16_searchCharacter($nom, $xapprule);
}?>

(Dit voorbeeld slaat nergens op; het geeft alleen een summier idee hoe PHP eruitziet.)

Ik weet niet wat ASP en JSP zijn.

Net zoiets als PHP. Maar ASP is van Microsoft, en JSP is gebaseerd op Java (een programmeertaal).
De meeste hobbyisten gebruiken PHP (en niet ASP of JSP).

Bij de Nijgh-input ben ik bezig geweest om alle binaire bestanden (zoals plaatjes) te indexen. Daar kan ik een pad, directory, subdirectory neerzetten. Is dat een oplossing?

Denk het niet.
Het probleem is dat je in de input moet kunnen voorspellen of je output in een subdirectory staat.
(Ik weet niet hoe ik mijn voorgaande tekst duidelijker moet maken.)

Ja, een optie in Dvegen om de input-files opnieuw te schrijven.

Dat wordt een behoorlijke klus, ALS het al mogelijk is zonder Dvegen helemaal opnieuw te maken.

Hoezo? Het gaat om een uiterst simpele manier van genereren.

Dan raad ik je aan dit niet met Dvegen te doen, maar met een scriptje. Dvegen is hier niet geschikt voor.

Vraag is hoe dat in een data-model past.
Bijvoorbeeld "wdc001-04-08-02"?
Dat zou panel 8.2 van het 4de verhaal van WDC 1 zijn.

Ik heb je datamodellen niet meer in mijn hoofd, maar ik zie zo gauw niet waarom dit niet zou kunnen.

Ik zou beide mogelijkheden willen bieden. Losse pagina's en lijsten.
Nu gaat het me vooral om het structureren van de input. Uiteindelijk wil ik daarmee een effectieve output kunnen leveren. Bijvoorbeeld, bij Barks, lijsten van verhalen met veranderingen. Lijsten van verhalen die in bv. 1960 zijn verschenen. Etc.

Als ik dit zo lees heb je echt iets dynamischers nodig dan Dvegen. Dus PHP.

Waarom dynamischer?

Omdat het nu een hele klus is om in Dvegen een ingewikkelde "query" te maken op je gegevens.
In PHP (met SQL) is dat een stuk simpeler.
Misschien is "flexibeler" een beter woord.

Ik denk (hoop) dat het meer gaat om het vaststellen van een universele input-structuur. Dus dat de input opnieuw moet worden opgebouwd, of tenminste strak gedefinieerd.

De inputstructuur van je data (de TXT-files) is eigenlijk niet eens zo ingewikkeld. Een andere programmeur zou dat zo kunnen inlezen, denk ik.
De andere files (DEF-files en tree.txt) zijn wat ingewikkelder.

Zodat Dvegen een van de mogelijkheden wordt om mee verder te experimenteren, maar niet perse de enige mogelijkheid. Als er een input is die door zowel Dvegen als door een ander programma (bv. MySQL) te interpreteren is, hetzij direct, hetzij via een vertaalslag, dan nodigt dat wellicht meer mensen uit om van de input gebruik te maken. De een in Dvegen en de ander in bv. PHP.

Yep.

Voorbeeldzin: "Ik ben dol op mijn Harries, maar zoveel aandacht als ze na de Playboy-reportage hebben gehad, slaat echt alles." (Georgina Verbaan)

In zo'n geval is het enkelvoud Harrie en niet Harry.

Hebben databaseprogramma MySQL en programmeertaal PHP andere methodes om te linken, naast die van HTML?

Ja, vergelijkbaar met hoe je het in de Dvegen-input hebt staan. Van bepaalde velden heb je in de TXT-file alleen de code van het te linken item staan. En in een DEF-file staat dan ergens dat die code gebruikt moet worden als HTML-linkje.
Zo sla je in een MySQL-tabel ook alleen de code op, terwijl je in de SQL-query bepaalt dat je die als link gebruikt naar een ander item.
(Goh, wat ingewikkeld om uit te leggen...)

[Daniel73]

Bij de Nijgh-input ben ik bezig geweest om alle binaire bestanden (zoals plaatjes) te indexen. Daar kan ik een pad, directory, subdirectory neerzetten. Is dat een oplossing?

Denk het niet.
Het probleem is dat je in de input moet kunnen voorspellen of je output in een subdirectory staat.
(Ik weet niet hoe ik mijn voorgaande tekst duidelijker moet maken.)

De binaire bestanden kunnen geplaatst worden in voorspelbare (sub)directories. Op alfabet bijvoorbeeld.
Helpt dat?

Bijvoorbeeld:
directory c:a*.* (http://xxxx.xx/a/*.*)
directory c:b*.* (http://xxxx.xx/b/*.*)
directory c:c*.* (http://xxxx.xx/c/*.*)

Ja, een optie in Dvegen om de input-files opnieuw te schrijven.

Dat wordt een behoorlijke klus, ALS het al mogelijk is zonder Dvegen helemaal opnieuw te maken.

Hoezo? Het gaat om een uiterst simpele manier van genereren.

Dan raad ik je aan dit niet met Dvegen te doen, maar met een scriptje. Dvegen is hier niet geschikt voor.

Kun jij zo'n sorteer-scriptje maken?
(Wat is het verschil tussen een "scriptje" en een programma?)

Vraag is hoe dat in een data-model past.
Bijvoorbeeld "wdc001-04-08-02"?
Dat zou panel 8.2 van het 4de verhaal van WDC 1 zijn.

Ik heb je datamodellen niet meer in mijn hoofd, maar ik zie zo gauw niet waarom dit niet zou kunnen.

Hieronder een voorbeeld van informatie die ik per panel zou willen indexen:

W OS 422-02 Donald Duck and the "The Gilded Man"

Appearances: British Guiana, South America (1.1); Blue Centennial stamp, worth ten cents apiece (1.1); Belgian Prince Leopold stamp, worth four bucks apiece (1.1); Green Bermuda stamp, worth sixty cents (2.7); 1932 Kookabura stamp from Australia, worth thirty cents (2.; stamp collector Philo T. Ellic, living at millionaire row "120 Swankmore Drive" (4.6); Sprigley (6.7); El Dorado, legendary gilded man (8.1); Sir Walter Raleigh, who made three expeditions up the Orinoco (8.3); Pedro (8.; Maria (8.; a stamp collector from Boston (9.4); Georgetown (9.6); the old riverman, whose father was the mail carrier from the river settlements to Georgetown in 1856 (10.4 12.1); Trader Corn, the oil man (10.7); 1856 One-cent Magenta stamp, worth more than fifty thousand dollars (1.5, 11.4); Mexico (17.1); his majesty (24.2); Dockside post office (24.5); Miss Susiebelle Swan, late distant relative of Gladstone Gander. In 1880 she left 60 Honker Street, Mudhen, Ohio, U.S.A., giving a forwarding address of 10 Quack Road, Webfoot, Oregon. In 1901 she floated away from Webfoot, said to forward her mail to 45 Mallard Avenue, Duckburg, Calisota (25.3, 25.7, 26.1, 27.2); Gizmo Tool and [...] factory, 45 Mallard Avenue, Duckburg, Calisota (26.5); San Francisco (29.5); Boston (29.; St. Louis (30.2); Chicago (29.5)

Philo T. Ellic's erroneous names for Gladstone Gander: Mr. Garfield (5.7); Mr. Gallstone Ginkle (6.4); Mr. Gillfinkle (6.7); Mr. Garland Goosepimple (6.; Mr. Goldbrick (29.5); Grindstone Gimmick (32.5)

http://www.seriesam.com/barks/comicsos0263.html#ccus_os0422-02

Hieronder wat quotes uit het verhaal, als onderdeel van een 'Inventory of Duck genealogy'. In dit geval over een familielid van Gladstone, genaamd Miss Susiebelle Swan.

25.3
employee Dockside post office: "Miss Susiebelle Swan, 60 Honker Street, Mudhen, Ohio, U.S.A."

25.4
employee Dockside post office: "Here! If miss Swan is still living, perhaps you can recover the letter from her!"

25.6
employee Mudhen post office: "No!... No miss Susiebelle Swan lives at that address!"

25.7
employee Mudhen post office: "She left in 1880! Gave a forwarding address of 10 Quack Road, Webfoot, Oregon!"

25.8
employee Webfoot post office: "No!.. No miss Susiebelle Swan lives at that address!"

26.1
employee Webfoot post office: "She floated away in 1901! Said to forward her mail to 45 Mallard Avenue, Duckburg, Calisota!"

26.2
nephew 1: "DUCKBURG!"
nephew 2: "That's our"
nephew 3: "HOME TOWN!"

26.3
Donald: "Now drive out to 45 Mallard Avenue and see if our Swan has flown!"

26.5
Donald: "Uh, oh! Big factory here now!"
[name: Gizmo tool and...]

27.1
employee Duckburg post office: "No mail for you today, Gladstone - but there's a letter here -"

27.2
employee Duckburg post office: "It's to your late distant relative, miss Susiebelle Swan! I believe she named you her sole HEIR!"
Gladstone Gander: "That's right!"

27.3
employee Duckburg post office: "Then I reckon YOU get the letter! Can't think of anyone who's more ENTITLED to it!"

- - - - - - - - - -

Dit soort informatie wil ik overzichtelijk kunnen plaatsen in een database. Het een en ander is nogal triviaal, waar Miss Swam gewoond heeft, maar ik denk dat dit leuk is voor wie bv. plattegronden en stambomen wil maken.

Ik zou beide mogelijkheden willen bieden. Losse pagina's en lijsten.
Nu gaat het me vooral om het structureren van de input. Uiteindelijk wil ik daarmee een effectieve output kunnen leveren. Bijvoorbeeld, bij Barks, lijsten van verhalen met veranderingen. Lijsten van verhalen die in bv. 1960 zijn verschenen. Etc.

Als ik dit zo lees heb je echt iets dynamischers nodig dan Dvegen. Dus PHP.

Waarom dynamischer?

Omdat het nu een hele klus is om in Dvegen een ingewikkelde "query" te maken op je gegevens.
In PHP (met SQL) is dat een stuk simpeler.
Misschien is "flexibeler" een beter woord.

De ingewikkelde queries in Dvegen hebben volgens mij te maken met ingewikkelde input. Bijvoorbeeld de subrecords in records. Misschien is hier de berg naar Mozes gegaan, in plaats van andersom? Oftewel, is het datamodel teveel custom-made?
Zou het het helpen als het datamodel alleen records gebruikt en geen unieke subrecords? Nu ik Barks-panels wil indexen, wordt een subrecord volgens mij wat onnodig. Zeker als het moeilijke queries oplevert. Want wat is dan nog een subrecord?

Zelf wil ik een vaste structuur voor de html-bestanden. Voordeel van html is dat ik een site zowel online kan zetten als op een CD-Rom. Met PHP is dat moeilijk.
Als ik een goede (sub)directory-structuur kan neerzetten waarover ik de duizenden bestanden netjes kan verdelen, heb ik voor mezelf genoeg aan vaste html. Ik moet ook ergens kunnen ophouden.

Het gaat me om het kunnen bieden van de mogelijkheid van PHP. Aan derden. Ik zou graag een zoekmachine willen met geadvanceerde opties om informatie te filteren en miniscuul te sorteren. Maar dat is een vak apart.
Wat ik wil doen is zorgen voor een tekst-input waar ik zelf mijn informatie in kwijt kan, en waar iemand anders probleemloos een simultane eigen site/interface uit kan opbouwen. Zoals bij jouw databases, bijvoorbeeld. Of idealiseer ik nu?

Ik denk (hoop) dat het meer gaat om het vaststellen van een universele input-structuur. Dus dat de input opnieuw moet worden opgebouwd, of tenminste strak gedefinieerd.

De inputstructuur van je data (de TXT-files) is eigenlijk niet eens zo ingewikkeld. Een andere programmeur zou dat zo kunnen inlezen, denk ik.
De andere files (DEF-files en tree.txt) zijn wat ingewikkelder.

Ik vraag me af of die ingewikkeldheid nodig is. Gaandeweg het maken van Dvegen zijn de eenheden die ik wil indexen kleiner geworden, en daar zijn subrecords uit ontstaan. Vroeger zou ik een panel als onderdeel van "stories" gezien hebben. Maar als ik een panel als eenheid neem, dan zou er geen subrecord voor nodig moeten zijn.

Een andere reden voor subrecords was dat er zodoende meerdere items per record kunnen worden gelinkt. Het toevoegen van informatie aan die items heeft de input naar ik vrees een custom-made gesmokkel geleverd, die het voor Dvegen moeilijk maakt om er via queries nog wijs uit te kunnen worden. Ik vraag me af of die omwegen nodig zijn in een database / content management system.

De oervorm van het subrecord was een apenstaartje:
#artiest@001
#artiest@002
(etc.)

Misschien moet het niet verder gaan dan zo'n verdieping? Als ik het door twee artiesten gemaakte 'Pirates Gold' index en daarbij ook de panels, dan zou het misschien logischer zijn om dat onder die panels-items te definiëren wie de artiest is.

Hier is, deels uit het hoofd, een fictief voorbeeld van een subrecord:
#-subrecord s_artiestlink
#-x_artiestlink barks
#-x_artiestpages pagina's 1 t/m 15
#-subrecord s_artiestlink
#-x_artiestlink gottfreddson
#-x_artiestpages pagina's 16 t/m 30
#-subrecord s_artiestlink
#-x_artiestlink strobl
#-x_artiestpages pagina's 31 t/m 45

Die "x_artiestpages" voegen extra informatie toe aan een record, die zodoende een item wordt. Een extra verdieping. Dat is voor mij op het eerste gezicht wel handig, maar is het wel zo netjes? Als ik dan toch persé (linkbare) informatie wil geven over pagina's, kan ik dan niet beter die pagina's als eenheid indexen?

Bijvoorbeeld:

#code wdc001-01-01-01
#artiest barks

#code wdc001-01-01-02
#artiest barks

#code wdc001-01-01-03
#artiest barks

#code wdc001-01-01-04
#artiest barks

(etc.)

#code wdc001-01-16-01
#artiest gottfreddson
#code wdc001-01-16-02
#artiest gottfreddson

(etc.)

Zou dat helpen? Het ziet er overdreven uit. Maar het zou volgens mij wel een subrecord-attribuut schelen. Wat dan weer een moeilijke query zou kunnen schelen in de DEF-files en tree.txt.
Probleem is nu dat ik de subrecords amper begrijp. Met name met lijsten. En volgens mij heb zelfs jij er als programmeur ook moeite mee, of valt dat mee? De DEF-files lijken nu soms hogere wiskunde om enigszins logica te vinden in wat ik als gebruiker op wil sommen.

Zodat Dvegen een van de mogelijkheden wordt om mee verder te experimenteren, maar niet perse de enige mogelijkheid. Als er een input is die door zowel Dvegen als door een ander programma (bv. MySQL) te interpreteren is, hetzij direct, hetzij via een vertaalslag, dan nodigt dat wellicht meer mensen uit om van de input gebruik te maken. De een in Dvegen en de ander in bv. PHP.

Yep.

Taak voor mij is nu een publiceerbare input te leveren. Probleem is nu dat er nu de input her en der wat informatie staat waarvan mij gevraagd is die offline te houden. Zoals namen van verzamelaars die vrezen voor diefstal.

Voorbeeldzin: "Ik ben dol op mijn Harries, maar zoveel aandacht als ze na de Playboy-reportage hebben gehad, slaat echt alles." (Georgina Verbaan)

In zo'n geval is het enkelvoud Harrie en niet Harry.

Hebben databaseprogramma MySQL en programmeertaal PHP andere methodes om te linken, naast die van HTML?

Ja, vergelijkbaar met hoe je het in de Dvegen-input hebt staan. Van bepaalde velden heb je in de TXT-file alleen de code van het te linken item staan. En in een DEF-file staat dan ergens dat die code gebruikt moet worden als HTML-linkje.
Zo sla je in een MySQL-tabel ook alleen de code op, terwijl je in de SQL-query bepaalt dat je die als link gebruikt naar een ander item.
(Goh, wat ingewikkeld om uit te leggen...)

Dit begrijp ik volgens mij wel.
Wat ik zou willen is een TXT-file die zowel met een DEF-file als een SQL-query kan communiceren.

[Snelbinder]

De binaire bestanden kunnen geplaatst worden in voorspelbare (sub)directories. Op alfabet bijvoorbeeld.
Helpt dat?

Nee. Lees mijn tekst nog eens en vertel me welk deel je niet snapt:

Het werkt dus als je ALLE outputfiles in een subdirectory zet (hoeft niet voor allemaal dezelfde te zijn). Dan wijst bijvoorbeeld "../img/blabla.jpg" altijd naar de goede directory.
Het gaat pas fout als sommige outputfiles in een subdirectory staan en andere niet. Dan kun je niet zomaar "../img/blabla.jpg" gebruiken, omdat dat dan soms naar de verkeerde directory wijst.
Dit is trouwens het enige probleem dat er nog is met subdirectory's.
In jouw geval wil je (denk ik) de "index.html" in de hoofddirectory hebben staan en alle andere html-files in (diverse) subdirectory's.
Hiervoor kan ik 2 simpele oplossingen bedenken:
1. gebruik op index.html geen enkel plaatje (of hooguit plaatjes met een afwijkend pad);
2. maak een index.html die een "redirect" bevat naar "subdir/index.html".

Ja, een optie in Dvegen om de input-files opnieuw te schrijven. Het gaat om een uiterst simpele manier van genereren.
Kun jij zo'n sorteer-scriptje maken?

Nee, ik ben niet zo'n script-goeroe.

De ingewikkelde queries in Dvegen hebben volgens mij te maken met ingewikkelde input. Bijvoorbeeld de subrecords in records. Misschien is hier de berg naar Mozes gegaan, in plaats van andersom? Oftewel, is het datamodel teveel custom-made?

Ik denk dat Dvegen alleen voor heel eenvoudige datamodellen werkt. Als je een link naar een link naar een link hebt (zoals bij Nijgh), wordt de DEF-file van Dvegen al gauw ingewikkeld.
Op zich heeft dat niet veel met subrecords te maken. Een subrecord is bijna een echt record. Alleen hoef je de link naar het "parent" record niet in de input te vermelden. En een subrecord heeft geen eigen #code (dat wil zeggen, Dvegen kent automatisch een code toe).

Nu ik Barks-panels wil indexen, wordt een subrecord volgens mij wat onnodig. Zeker als het moeilijke queries oplevert. Want wat is dan nog een subrecord?

Ja, misschien wordt de input wel overzichtelijker zonder subrecords. Dat kost een hoop tikwerk, maar misschien is het die moeite wel waard.

Ik moet ook ergens kunnen ophouden.

Wat ik wil doen is zorgen voor een tekst-input waar ik zelf mijn informatie in kwijt kan, en waar iemand anders probleemloos een simultane eigen site/interface uit kan opbouwen. Zoals bij jouw databases, bijvoorbeeld. Of idealiseer ik nu?

Een tijd geleden dacht ik dat dit met die XML-optie die ik heb ingebouwd wel zou lukken.
Maar ik gebruik XML zelf te weinig om te beoordelen of dat makkelijk is. Eigenlijk zou een XML-expert hier iets over moeten zeggen.

Zo werkt het bij Inducks/COA (volgens http://bolderbast.inducks.org/xh8.html):



Vervang hier wat kreten en je hebt wat jij wil:
*.DB* --> Dvegen-input
*.log --> Dvegen-logfile
DIZNI --> Dvegen
*.ISV --> files in een algemeen bruikbaar formaat
COA import --> een eenvoudig scriptje voor inlezen in SQL-database
COA website --> een nog te bouwen website in PHP

Misschien moeten we dus eens gaan denken over zo'n ISV-achtig formaat. Daarvoor hebben we een echt goed datamodel nodig.
Dvegen is wat relaxeder: daarbij kun je je datamodel wat slordiger definiëren (en makkelijker velden toevoegen e.d.).
Voor zo'n strict datamodel zal ik Dvegen dan nog wel flink moeten aanpassen.

Een andere reden voor subrecords was dat er zodoende meerdere items per record kunnen worden gelinkt. Het toevoegen van informatie aan die items heeft de input naar ik vrees een custom-made gesmokkel geleverd, die het voor Dvegen moeilijk maakt om er via queries nog wijs uit te kunnen worden. Ik vraag me af of die omwegen nodig zijn in een database / content management system.

Ja, dat is nodig. Als je vanuit meerdere records naar meerdere andere records wilt linken (en dat wil jij), dan heb je daarvoor extra tabellen nodig.
Dat is ook niet abnormaal of zo.

De oervorm van het subrecord was een apenstaartje:
#artiest@001
#artiest@002
(etc.)

Misschien moet het niet verder gaan dan zo'n verdieping?

Ik zou juist van die @s af willen. Die maken het geheel ingewikkeld. Bovendien lijkt het daardoor minder op een "echte" database.

... Dat is voor mij op het eerste gezicht wel handig, maar is het wel zo netjes? Als ik dan toch persé (linkbare) informatie wil geven over pagina's, kan ik dan niet beter die pagina's als eenheid indexen?

Dit is geen kwestie van netjes of niet netjes. Je moet altijd een afweging maken tussen hoe flexibel je wil zijn en hoeveel dubbel werk je wil hebben.
Je kan dus een keuze maken uit:
- ieder verhaal heeft een aantal artiesten (de simpelste oplossing. Maar de informatie bij uitzonderingen is niet gestructureerd.)
- iedere pagina heeft een aantal artiesten (dus voor alle 6000 Barks-pagina's heb je een record in je database nodig)
- allebei (je datamodel wordt ingewikkelder, want om te kijken welke artiest bij een pagina hoort moet je in 2 tabellen kijken.)

Ikzelf nijgh vaak naar de "simpele" keuze. Dus dat uitzonderingen het datamodel niet bepalen.
Maar de ene keuze is niet per definitie netter dan de andere.

Probleem is nu dat ik de subrecords amper begrijp. Met name met lijsten. En volgens mij heb zelfs jij er als programmeur ook moeite mee, of valt dat mee? De DEF-files lijken nu soms hogere wiskunde om enigszins logica te vinden in wat ik als gebruiker op wil sommen.

Inderdaad. Het kost mij vaak een behoorlijke tijd om er in te duiken. Ook al omdat ik niet dagelijks in die materie zit.

Bij tijd en gelegenheid zal ik eens kijken of Dvegen iets ISV-achtigs kan produceren.
(Wegens ziekte en vakanties wil ik niet beloven direct volgende week al iets te hebben...)

[Daniel73]

Alvast een korte reactie:

Ja, een optie in Dvegen om de input-files opnieuw te schrijven. Het gaat om een uiterst simpele manier van genereren.
Kun jij zo'n sorteer-scriptje maken?

Nee, ik ben niet zo'n script-goeroe.

Kun je dan een programma maken dat input kan converteren naar input? Zo'n optie is voor mij heel belangrijk, omdat ik nu gaandeweg met een steeds chaotischere input kom te zitten.

Nu kan ik alleen van een chaotisch tekstbestand naar een geordend HTML-bestand gaan. Ik heb er nooit bij stilgestaan dat het genereren van txt naar txt een probleem zou zijn.
Dit is wat ik o.m. bedoel met een export-functie.

Ik hoop dat je me hiermee kunt helpen, omdat ik anders op een dood spoor zit. (paniek!)
Nu heb ik txt-bestanden waarmee ik mezelf de hoek in schilder. Een enkele foute beslissing en een txt-bestand is al een chaos.

[Daniel73]

Bij tijd en gelegenheid zal ik eens kijken of Dvegen iets ISV-achtigs kan produceren.
(Wegens ziekte en vakanties wil ik niet beloven direct volgende week al iets te hebben...)

Beterschap en prettige vakanties.

[Daniel73]

De ingewikkelde queries in Dvegen hebben volgens mij te maken met ingewikkelde input. Bijvoorbeeld de subrecords in records. Misschien is hier de berg naar Mozes gegaan, in plaats van andersom? Oftewel, is het datamodel teveel custom-made?

Ik denk dat Dvegen alleen voor heel eenvoudige datamodellen werkt. Als je een link naar een link naar een link hebt (zoals bij Nijgh), wordt de DEF-file van Dvegen al gauw ingewikkeld.

Ingewikkeld vind ik op zich geen probleem. Zolang het werk maar lonend, verantwoord en overdraagbaar is.
Wat misschien zou helpen is een datamodel. En een FAQ met voorbeeld-schema's voor DEF-bestanden.

Bestaan driedimensionale datamodellen?

Op zich heeft dat niet veel met subrecords te maken. Een subrecord is bijna een echt record. Alleen hoef je de link naar het "parent" record niet in de input te vermelden. En een subrecord heeft geen eigen #code (dat wil zeggen, Dvegen kent automatisch een code toe).

Is een subrecord te begrijpen voor database-modellen, van jezelf en van derden?
Wat misschien helpt is strak definiëren wat in een datamodel een subrecord is en wat een echt record. Nu kan een subrecord van alles bevatten, zoals teveel extra informatie. Wanneer is een subrecord het waard om echt echt record te worden? Dat soort bepalingen.

De onnozele gebruiker (zoals ik dus) kan er nu misschien teveel een eigen feestje bouwen. Waarbij de programmeur dan mag gaan uitvissen hoe die vrije creativiteit redelijkerwijs in te passen in een programma.

Wat ik zou willen is een definiëring van een (internationale) standaard die niet alleen bij Nijgh en Barks werkt, maar waarmee ook andere artiesten en werken behandeld kunnen worden.
Een data-sjabloon, als het ware. Vul dat sjabloon maar in, draai Dvegen, en je hebt een site. Of, in het ideale geval, upload (of e-mail) de gemaakte input en je hebt bijgedragen aan een site.

Nu ik Barks-panels wil indexen, wordt een subrecord volgens mij wat onnodig. Zeker als het moeilijke queries oplevert. Want wat is dan nog een subrecord?

Ja, misschien wordt de input wel overzichtelijker zonder subrecords. Dat kost een hoop tikwerk, maar misschien is het die moeite wel waard.

Ik wil de subrecords niet helemaal kwijt. Ik hoop ze wel te kunnen minimaliseren. Misschien zijn ze handig als vangnet voor uitzonderingen?

Verder wil ik duidelijk definiëren welke informatie geschikt is voor output-overzichten zoals tabellen.
Zo zou ik in een tabel een grafische weergave kunnen maken van het aantal strippagina's dat Barks per jaar heeft gemaakt, waarbij onderscheid gemaakt kan worden tussen art-only, script-only en beide.
En bijvoorbeeld via een programma als Excel, visuele grafische weergaven zoals die bijvoorbeeld te zien zijn op televisie-journaals in aanloop naar politieke verkiezingen.

Dit zijn zaken waar ik rekening mee wil houden bij het tikwerk.
Met Barks en Nijgh heb ik nu wel alle uithoeken getest, denk ik. Dus ik denk dat het nu tijd is om te consolideren. Daarvoor zou ik een lijst kunnen maken van welke type items, welke velden en welke subvelden er zijn. Uitgangspunt is dat Barks en Nijgh in hetzelfde datamodel passen.
Voor een database maakt het weinig verschil of het gaat om liedjes, uitvoeringen en platen, of over strips, schilderijen en publicaties, dat maakt op zich niet zoveel uit. Heb ik ontdekt, tenminste.

Nijgh is overigens amateur-illustrator voor een schoolkrant geweest, en Barks heeft een gedicht geschreven.
Dit ter voorbeeld-illustratie van mijn formule Barks = Nijgh.

Wat ik wil doen is zorgen voor een tekst-input waar ik zelf mijn informatie in kwijt kan, en waar iemand anders probleemloos een simultane eigen site/interface uit kan opbouwen. Zoals bij jouw databases, bijvoorbeeld. Of idealiseer ik nu?

Een tijd geleden dacht ik dat dit met die XML-optie die ik heb ingebouwd wel zou lukken.
Maar ik gebruik XML zelf te weinig om te beoordelen of dat makkelijk is. Eigenlijk zou een XML-expert hier iets over moeten zeggen.

Zo werkt het bij Inducks/COA (volgens http://bolderbast.inducks.org/xh8.html):



Vervang hier wat kreten en je hebt wat jij wil:
*.DB* --> Dvegen-input
*.log --> Dvegen-logfile
DIZNI --> Dvegen
*.ISV --> files in een algemeen bruikbaar formaat
COA import --> een eenvoudig scriptje voor inlezen in SQL-database
COA website --> een nog te bouwen website in PHP

Misschien moeten we dus eens gaan denken over zo'n ISV-achtig formaat. Daarvoor hebben we een echt goed datamodel nodig.
Dvegen is wat relaxeder: daarbij kun je je datamodel wat slordiger definiëren (en makkelijker velden toevoegen e.d.).
Voor zo'n strict datamodel zal ik Dvegen dan nog wel flink moeten aanpassen.

Die slordigheid wil ik proberen te mijden. Het zomaar velden toevoegen wil ik beperkt houden. De meeste veranderingen en toevoegingen tot dusver zijn een zoektocht naar wat een geschikt, universeel totaal-model kan zijn.
Ik zou het zonde vinden als ik al deze moeite alleen voor Barks en Nijgh deed. Al was het maar omdat ik zelf meer artiesten heb die ik zou willen behandelen, zoals bv. Barrett. En misschien zou een Al Taliaferro- of een Floyd Gottfredson-encyclopedie ook leuk zijn, om maar wat voorbeelden te noemen.

Een andere reden voor subrecords was dat er zodoende meerdere items per record kunnen worden gelinkt. Het toevoegen van informatie aan die items heeft de input naar ik vrees een custom-made gesmokkel geleverd, die het voor Dvegen moeilijk maakt om er via queries nog wijs uit te kunnen worden. Ik vraag me af of die omwegen nodig zijn in een database / content management system.

Ja, dat is nodig. Als je vanuit meerdere records naar meerdere andere records wilt linken (en dat wil jij), dan heb je daarvoor extra tabellen nodig.
Dat is ook niet abnormaal of zo.

Oke.

De oervorm van het subrecord was een apenstaartje:
#artiest@001
#artiest@002
(etc.)

Misschien moet het niet verder gaan dan zo'n verdieping?

Ik zou juist van die @s af willen. Die maken het geheel ingewikkeld. Bovendien lijkt het daardoor minder op een "echte" database.

Precies andersom als dat ik dacht. Mij leek het programma-technisch handig dat de apenstaart fysiek gekoppeld is aan een veld. Maar ja, ik ben dus geen programmeur.
Ik zal de apenstaarten alle vervangen. Als ik dat nog niet gedaan heb.

... Dat is voor mij op het eerste gezicht wel handig, maar is het wel zo netjes? Als ik dan toch persé (linkbare) informatie wil geven over pagina's, kan ik dan niet beter die pagina's als eenheid indexen?

Dit is geen kwestie van netjes of niet netjes. Je moet altijd een afweging maken tussen hoe flexibel je wil zijn en hoeveel dubbel werk je wil hebben.
Je kan dus een keuze maken uit:
- ieder verhaal heeft een aantal artiesten (de simpelste oplossing. Maar de informatie bij uitzonderingen is niet gestructureerd.)
- iedere pagina heeft een aantal artiesten (dus voor alle 6000 Barks-pagina's heb je een record in je database nodig)
- allebei (je datamodel wordt ingewikkelder, want om te kijken welke artiest bij een pagina hoort moet je in 2 tabellen kijken.)

Ikzelf nijgh vaak naar de "simpele" keuze. Dus dat uitzonderingen het datamodel niet bepalen.
Maar de ene keuze is niet per definitie netter dan de andere.

Ik wil zo min mogelijk uitzonderingen. Door te definiëren wat uitzonderingen zijn. Hoeveel uitzonderingen kun je hebben voordat ze geen uitzonderingen zijn? Het woord "uitzondering" is zeker in meervoud een tegenspraak op zich.

Zo denk ik dat het een groot verschil maakt of je Barks behandelt als (1) Disney striptekenaar, als (2) Disney artiest of (3) als artiest.
In het eerste geval heb je een probleem als de man ook schilder blijkt. In het derde geval maakt het niet uit of het gaat om een schilderij of een strippagina. Een schilderij zou een pagina van één panel kunnen zijn, zoals een voorplaat.

Mijn gedachte is:
Het gaat om een artiest die een werk heeft gemaakt dat is gepubliceerd.
Of andersom: Een werk is gepubliceerd dat is gemaakt door een artiest.

Artiest, werk en publicatie zijn afzonderlijke types items.
Zo kan een werk veranderd zijn in een of meer publicaties.
Of andersom, een publicatie kan origineler zijn omdat het originele werk inmiddels is gewijzigd. (Zoals het wensput-schilderij van Barks.)

Ikzelf nijgh

Je nijght?

Over spelling gesproken: Op de achterkant van Donald Duck 1994-03 is volgens een opschrift onder een vis een "harrie" te zien, in het laatste plaatje. (H93164) Die kwam ik toevallig tegen in een stapel afgedankte ducks.

Probleem is nu dat ik de subrecords amper begrijp. Met name met lijsten. En volgens mij heb zelfs jij er als programmeur ook moeite mee, of valt dat mee? De DEF-files lijken nu soms hogere wiskunde om enigszins logica te vinden in wat ik als gebruiker op wil sommen.

Inderdaad. Het kost mij vaak een behoorlijke tijd om er in te duiken. Ook al omdat ik niet dagelijks in die materie zit.

Mijn doelstelling is dat je er niet onnodig lang in hoeft te duiken, door duidelijk uiteen te zetten waar welke data thuishoort in het totaalmodel.
Nu maken de inputbestanden voor Barks en Nijgh zelfs gebruik van verschillende veldnamen die voor elk, zowel Barks als Nijgh, hetzelfde kunnen zijn. Dat kost jou dan meer tijd. Terwijl dat nergens goed voor is.

Bij tijd en gelegenheid zal ik eens kijken of Dvegen iets ISV-achtigs kan produceren.

Ik ben benieuwd. Helpt het misschien als ik eerst uiteenzet wat ik wil met een totaalmodel? Al was het maar een één op één vergelijking tussen Nijgh en Barks?
Als Barks=Nijgh heb je maar één datamodel nodig om iets ISV-achtigs van te maken. Of maakt dat niet uit?

*EDIT*: foutieve koptekst ("KLAD") verwijderd

[Snelbinder]

Kun je dan een programma maken dat input kan converteren naar input? Zo'n optie is voor mij heel belangrijk, omdat ik nu gaandeweg met een steeds chaotischere input kom te zitten.

Aangezien dit een geheel nieuwe tak van sport is, hoop ik dat je hier iemand anders voor vindt.
Het lijkt me alleen al een klus om uit te vinden wat je precies "chaotisch" vindt en wat "geordend".

Over je datamodel: misschien is het aardig om een datamodel op te zetten voor zowel Barks als Nijgh. Daar had je het al over.
Wat je dus nodig hebt is het volgende:

- welke "objecten" zijn er? (bijvoorbeeld Person, Artwork)
- welke "kenmerken" hebben deze objecten? (bijvoorbeeld een Person heeft een Surname)
- welke "relaties" zijn er tussen de objecten? (bijvoorbeeld een Person heeft nul of meer Artwork geschreven; een Person heeft nul of meer Artwork getekend; een Artwork is een gewijzigde versie van een ander Artwork, ...)

Denk je dat je een lijst met deze drie dingen kunt maken? Of eventueel in tekstvorm?
Voor Nijgh heb ik dat ooit in een (nogal ingewikkelde) tekening proberen te doen. Zo'n tekening kan er bijvoorbeeld uitzien zoals dit Inducks-plaatje:



Let hierbij niet op de exacte invulling - jouw model is Inducks niet (en het plaatje laat maar een deel van het Inducks-model zien). En let ook niet op de groene kleurtjes en op details zoals PK en FK1.

Maar afgezien daarvan: begrijp je een beetje wat ik bedoel?

[Snelbinder]

Aanvullend op bovenstaande.
Ik zie dat je mijn vraag al gedeeltelijk beantwoordt:

Het gaat om een artiest die een werk heeft gemaakt dat is gepubliceerd.
Of andersom: Een werk is gepubliceerd dat is gemaakt door een artiest.
Artiest, werk en publicatie zijn afzonderlijke types items.
Zo kan een werk veranderd zijn in een of meer publicaties.
Of andersom, een publicatie kan origineler zijn omdat het originele werk inmiddels is gewijzigd.

Zo'n verhaal bedoel ik dus, maar dan veel verder uitgewerkt. Je zegt hier "Een werk is gepubliceerd dat is gemaakt door een artiest" maar daarbij vergeet je dat er meer dan 1 artiest betrokken kunnen zijn bij een werk. En je laat buiten beschouwing dat er werken zijn die niet gepubliceerd zijn.
Als je al dat soort keuzes hebt gemaakt, krijg je een consistent model.
Maar je moet dus vaak een keuze maken of je iets beschouwt als "uitzondering" of dat je het in het model wil meenemen.

*EDIT*: foutieve koptekst ("KLAD") verwijderd

Tja, jij als forumbaas mag je berichten achteraf nog editen. Andere mensen niet...

[Daniel73]

Tja, jij als forumbaas mag je berichten achteraf nog editen. Andere mensen niet...

Editen doe ik bij uitzondering, op voorwaarden, en altijd met een verantwoording (een uitleg) erbij. Iedereen kan een verzoek indienen.

Het kopje "KLAD" was per ongeluk meegekopieerd. Dat vond ik een misleidende layout-fout. Spelfouten en typefouten zie ik, óók voor die van mijzelf, als eigen schuld dikke bult. Uitzonderingen worden verantwoord. Zoals iemand die een woord in een gedicht verkeerd overtypte.

Reden waarom "edit" uitstaat is dat men daarmee, standaard, tot in St. Juttemis berichten zomaar kan wijzigingen. Dat wil ik beperken.

Zie: Berichten editen
http://bb.mcdrake.nl/nedofftopic/viewtopic.php?t=277

[Daniel73]

Kun je dan een programma maken dat input kan converteren naar input? Zo'n optie is voor mij heel belangrijk, omdat ik nu gaandeweg met een steeds chaotischere input kom te zitten.

Aangezien dit een geheel nieuwe tak van sport is, hoop ik dat je hier iemand anders voor vindt.
Het lijkt me alleen al een klus om uit te vinden wat je precies "chaotisch" vindt en wat "geordend".

Zodra je, waar dan ook, een klus hebt om uit te vinden wat DVEGEN moet doen, heb ik iets fout gedaan. Ik moet immers klip-en-klaar definiëren wat een programma domweg moet doen. Dat heb ik in het verleden vaak onderschat.

Volgens mij hebben we hier een spraakverwarring. (Hoop ik.) Ik begrijp niet wat je niet van mij begrijpt. Wat "chaotisch" en wat "geordend" is, hoef je helemaal niet uit te vinden.
Ik meen zelfs dat we dit ooit per telefoon overlegd hebben, en dat het toen wel leek te kunnen.

Wat ik nodig heb is een manier om velden in een andere, door mij opgegeven volgorde te zetten. Waarbij opdrachten (zoals %link) NIET worden uitgevoerd.

Fictief voorbeeld:

INPUT.TXT:

#veld4 boter
#veld2 kaas
#veld3 Pietersen
#veld1 100 stuks

Bovenstaande volgorde wil ik anders hebben. Toevallig(!) op alfabetische volgorde van veldnaam. Dus ik maak dan een DEF-bestand waarin ik die gewenste volgorde neerzet, zoals ik dat ook doe als ik normaal met DVEGEN werk.

DEF.TXT:

#veld1 "##veld1 %val"
#veld2 "##veld2 %val"
#veld3 "##veld3 %val"
#veld4 "##veld4 %val

(Ik zet twee hekjes neer om aan te geven dat het gaat om een te printen tekst. Zoals "%%" nu een enkele "%" wordt in de output.)

Door dit "DEF"-bestand is voor DVEGEN (en jou en iedereen) te zien wat ik geordend vind. Namelijk die opgegeven volgorde. Want die volgorde heb ik immers gedefinieerd. Zoals ik altijd volgordes definieer die DVEGEN volgt bij het maken van de output.
Verschillen zijn dat de #veldnaam meegeprint moet worden ("##veldnaam" moet dan worden "#veldnaam"), en dat DVEGEN géén %-opdrachten uitvoert maar ze domweg kopieert.

OUTPUT.TXT (rename as "INPUT.TXT")

#veld1 100 stuks
#veld2 kaas
#veld3 Pietersen
#veld4 boter

Mocht ik toch een andere volgorde willen, door voortschrijdend inzicht, dan kan ik die zelf weer in DEF definiëren. Waarna het proces opnieuw begint. Zoals ik nu ook met DVEGEN werk.

Probleem, zoals te zien in het voorbeeld, is dat ik veldnamen moet overtypen als te printen tekst. Ik zou een opdracht nodig hebben die opdraagt: print fieldname.

Als DVEGEN niet automatisch alle opdrachten zou uitvoeren, maar een relax-functie zou hebben, zou ik volgens mij nu al een eind kunnen komen met huidige DVEGEN. Want dan worden de opdrachten als zijnde gewone tekst gegenereerd.
Het bovenstaande voorbeeld moet ik, volgens mij, kunnen simuleren met het huidige DVEGEN. Zal ik dat doen?

Over je datamodel: misschien is het aardig om een datamodel op te zetten voor zowel Barks als Nijgh. Daar had je het al over.
Wat je dus nodig hebt is het volgende:

- welke "objecten" zijn er? (bijvoorbeeld Person, Artwork)
- welke "kenmerken" hebben deze objecten? (bijvoorbeeld een Person heeft een Surname)
- welke "relaties" zijn er tussen de objecten? (bijvoorbeeld een Person heeft nul of meer Artwork geschreven; een Person heeft nul of meer Artwork getekend; een Artwork is een gewijzigde versie van een ander Artwork, ...)

Denk je dat je een lijst met deze drie dingen kunt maken? Of eventueel in tekstvorm?

Ja. Ik denk dat ik dat kan.
Lijstvorm lijkt me het beste. Vrije tekst wordt bij mij al gauw een woordenwaterval. (Bla bla bla bla bla...)

Voor Nijgh heb ik dat ooit in een (nogal ingewikkelde) tekening proberen te doen. Zo'n tekening kan er bijvoorbeeld uitzien zoals dit Inducks-plaatje:

http://bolderbast.inducks.org/datamodel/IndNewModel53_raster.jpg

Maak je dat overzicht handmatig, of heb je er een programma/sjabloon voor?
Zo'n overzicht zou ik zelf ook handig vinden. Nu verdwaal ik in mijn eigen wereld.

Let hierbij niet op de exacte invulling - jouw model is Inducks niet (en het plaatje laat maar een deel van het Inducks-model zien). En let ook niet op de groene kleurtjes en op details zoals PK en FK1.

Maar afgezien daarvan: begrijp je een beetje wat ik bedoel?

Ja, ik denk van wel.

Aanvullend op bovenstaande.
Ik zie dat je mijn vraag al gedeeltelijk beantwoordt:

Het gaat om een artiest die een werk heeft gemaakt dat is gepubliceerd.
Of andersom: Een werk is gepubliceerd dat is gemaakt door een artiest.
Artiest, werk en publicatie zijn afzonderlijke types items.
Zo kan een werk veranderd zijn in een of meer publicaties.
Of andersom, een publicatie kan origineler zijn omdat het originele werk inmiddels is gewijzigd.

Zo'n verhaal bedoel ik dus, maar dan veel verder uitgewerkt. Je zegt hier "Een werk is gepubliceerd dat is gemaakt door een artiest" maar daarbij vergeet je dat er meer dan 1 artiest betrokken kunnen zijn bij een werk. En je laat buiten beschouwing dat er werken zijn die niet gepubliceerd zijn.
Als je al dat soort keuzes hebt gemaakt, krijg je een consistent model.
Maar je moet dus vaak een keuze maken of je iets beschouwt als "uitzondering" of dat je het in het model wil meenemen.

Misschien kan ik veld maken dat #uitzondering heet?
Ik kan beginnen met een lijst waarin ik verzamel wat ik nu reeds in veldnamen en subrecords heb staan. Met bij elk een uitleg wat de functie is. Eigenlijk was dat de afspraak, maar daar heb ik gaandeweg een rommeltje van gemaakt.

Bijvoorbeeld, ik verzin maar wat:

#code
uitleg: identificatie van item.

#artiest
uitleg: artiest; enkelvoud; alleen artiestcode invoeren

#externlink
uitleg: internet-link; enkelvoud; alleen kale link invoeren

etc.

Is dat oké?

Komende tijd heb ik nog veel stress om mijn computer. Dit is al de tweede computer die slecht is afgeleverd. En bij elke reparatie ontstaat een nieuw probleem. Raadpleeg uw leverancier... ja ja. Dus ik zal nog even tobben met het vinden van wel een goede reparatiedienst. Een en ander zorgt voor vertraging.
Waar o waar is mijn mechanische typemachine van weleer gebleven? We hadden het zo goed samen...