Daniel73 schreef: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.
Snelbinder schreef:Style sheets en javascript is geen probleem.
Voor PHP en dergelijke (ik neem aan dat je met "active scripts" dingen bedoelt als ASP en JSP) heb je een programma op de server nodig (bijvoorbeeld Tomcat). Het hangt dus van je provider af of zo'n programma beschikbaar is.
Snelbinder schreef: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.
Snelbinder schreef: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.
Snelbinder schreef: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.
Snelbinder schreef: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.
Snelbinder schreef: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.)
Snelbinder schreef: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.
Snelbinder schreef: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: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:[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.)
Snelbinder schreef:Daniel73 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...
Snelbinder schreef: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.
Snelbinder schreef: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 schreef:Daniel73 schreef: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 schreef:Kan Dvegen werken met PHP?
Daniel73 schreef:Wat zijn "active scripts"?
Daniel73 schreef: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.
Daniel73 schreef:Ja, een optie in Dvegen om de input-files opnieuw te schrijven.
Daniel73 schreef:Ik wil niet alleen moleculen maar ook atomen kunnen indexen.
Daniel73 schreef:Vraag is hoe dat in een data-model past.
Daniel73 schreef: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.
Daniel73 schreef: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.
Daniel73 schreef: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.
Daniel73 schreef:Het lijkt me stug dat ik zomaar een loodzware Dvegen kan gaan draaien
Daniel73 schreef:Snelbinder schreef:[meerdere output-directories]
Daniel73 schreef: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?
Daniel73 schreef: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?
Daniel73 schreef:Kunnen formaten als MySQL, PHP, etc., daarmee omgaan, met inge(b?)akken HTML-codes?
Snelbinder schreef:Daniel73 schreef: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.
Snelbinder schreef:Daniel73 schreef:Wat zijn "active scripts"?
Geen idee.
Jij kwam met die kreet. Ik probeerde alleen te interpreteren wat je ermee zou kunnen bedoelen.
Snelbinder schreef:Daniel73 schreef: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".
Snelbinder schreef:Daniel73 schreef: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.
Snelbinder schreef:Daniel73 schreef:Ik wil niet alleen moleculen maar ook atomen kunnen indexen.
Zo heb je wel werk gecreëerd voor jezelf voor de komende 10 jaar.
Snelbinder schreef:Daniel73 schreef: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.
Snelbinder schreef:Daniel73 schreef: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.)
Snelbinder schreef:Daniel73 schreef: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...
Snelbinder schreef:Daniel73 schreef: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.
Snelbinder schreef:Snelbinder schreef:[meerdere output-directories]
Nee, dat heb ik niet geschreven. Ik zou nooit directory's verkeerd spellen.
Snelbinder schreef:Daniel73 schreef: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.
Snelbinder schreef:Daniel73 schreef: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 schreef:Wat voor input-formaat heeft PHP nodig, als taaltje om HTML te genereren?
<?php
include('header.php');
$colo1 = "#ffcc33";
$colo2 = "#cbdced";
if ($c2) {
echo "<table border=0>";
$nom = $c2;
$charactercodeArray = util16_searchCharacter($nom, $xapprule);
}?>
Daniel73 schreef:Ik weet niet wat ASP en JSP zijn.
Daniel73 schreef: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?
Daniel73 schreef:Ja, een optie in Dvegen om de input-files opnieuw te schrijven.
"ik" schreef:Dat wordt een behoorlijke klus, ALS het al mogelijk is zonder Dvegen helemaal opnieuw te maken.
Daniel73 schreef:Hoezo? Het gaat om een uiterst simpele manier van genereren.
Daniel73 schreef: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.
Daniel73 schreef: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.
Snelbinder schreef:Als ik dit zo lees heb je echt iets dynamischers nodig dan Dvegen. Dus PHP.
Daniel73 schreef:Waarom dynamischer?
Daniel73 schreef: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.
Daniel73 schreef: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.
Daniel73 schreef:Voorbeeldzin: "Ik ben dol op mijn Harries, maar zoveel aandacht als ze na de Playboy-reportage hebben gehad, slaat echt alles." (Georgina Verbaan)
Daniel73 schreef:Hebben databaseprogramma MySQL en programmeertaal PHP andere methodes om te linken, naast die van HTML?
Snelbinder schreef:Daniel73 schreef: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.)
Snelbinder schreef:Daniel73 schreef:Ja, een optie in Dvegen om de input-files opnieuw te schrijven."ik" schreef:Dat wordt een behoorlijke klus, ALS het al mogelijk is zonder Dvegen helemaal opnieuw te maken.Daniel73 schreef: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.
Snelbinder schreef:Daniel73 schreef: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.
Snelbinder schreef:Daniel73 schreef: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.Snelbinder schreef:Als ik dit zo lees heb je echt iets dynamischers nodig dan Dvegen. Dus PHP.Daniel73 schreef: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.
Snelbinder schreef:Daniel73 schreef: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.
Snelbinder schreef:Daniel73 schreef: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.
Snelbinder schreef:Daniel73 schreef: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.
Snelbinder schreef:Daniel73 schreef: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 schreef:De binaire bestanden kunnen geplaatst worden in voorspelbare (sub)directories. Op alfabet bijvoorbeeld.
Helpt dat?
"ik" schreef: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".
Daniel73 schreef: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?
Daniel73 schreef: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?
Daniel73 schreef: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?
Daniel73 schreef:Ik moet ook ergens kunnen ophouden.
Daniel73 schreef: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?
Daniel73 schreef: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.
Daniel73 schreef:De oervorm van het subrecord was een apenstaartje:
#artiest@001
#artiest@002
(etc.)
Misschien moet het niet verder gaan dan zo'n verdieping?
Daniel73 schreef:... 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?
Daniel73 schreef: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.
Snelbinder schreef:Daniel73 schreef: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.
Snelbinder schreef: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...)
Snelbinder schreef:Daniel73 schreef: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.
Snelbinder schreef: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).
Snelbinder schreef:Daniel73 schreef: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.
Snelbinder schreef:Daniel73 schreef: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.
Snelbinder schreef:Daniel73 schreef: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.
Snelbinder schreef:Daniel73 schreef: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.
Snelbinder schreef:Daniel73 schreef:... 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.
Snelbinder schreef:Ikzelf nijgh
Snelbinder schreef:Daniel73 schreef: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.
Snelbinder schreef:Bij tijd en gelegenheid zal ik eens kijken of Dvegen iets ISV-achtigs kan produceren.
Daniel73 schreef: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.
Daniel73 schreef: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.
Daniel73 schreef:*EDIT*: foutieve koptekst ("KLAD") verwijderd
Snelbinder schreef:Tja, jij als forumbaas mag je berichten achteraf nog editen. Andere mensen niet...
Snelbinder schreef:Daniel73 schreef: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".
#veld4 boter
#veld2 kaas
#veld3 Pietersen
#veld1 100 stuks
#veld1 "##veld1 %val"
#veld2 "##veld2 %val"
#veld3 "##veld3 %val"
#veld4 "##veld4 %val
#veld1 100 stuks
#veld2 kaas
#veld3 Pietersen
#veld4 boter
Snelbinder schreef: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?
Snelbinder schreef: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
Snelbinder schreef: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 schreef:Aanvullend op bovenstaande.
Ik zie dat je mijn vraag al gedeeltelijk beantwoordt:Daniel73 schreef: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.
#code
uitleg: identificatie van item.
#artiest
uitleg: artiest; enkelvoud; alleen artiestcode invoeren
#externlink
uitleg: internet-link; enkelvoud; alleen kale link invoeren
etc.
Keer terug naar Computers en internet
Gebruikers op dit forum: Geen geregistreerde gebruikers. en 7 gasten