<?xml version="1.0" encoding="utf-8"?><!-- generator="b2evolution/6.10.3-stable" -->
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:admin="http://webns.net/mvcb/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>E-learn Weblog of Willem van Valkenburg - Latest Comments on 2de Blackboard building block ruilbeurs</title>
		<link>http://www.e-learn.nl/?disp=comments</link>
		<atom:link rel="self" type="application/rss+xml" href="http://www.e-learn.nl/?tempskin=_rss2&#38;disp=comments&#38;p=246" />
		<description></description>
		<language>en-UK</language>
		<docs>http://backend.userland.com/rss</docs>
		<admin:generatorAgent rdf:resource="http://b2evolution.net/?v=6.10.3-stable"/>
		<ttl>60</ttl>
		<item>
			<title> Erwin Brinkhuis [Visitor] in response to: 2de Blackboard building block ruilbeurs</title>
			<pubDate>Wed, 04 Apr 2007 15:14:08 +0000</pubDate>
			<dc:creator><span class="user anonymous" rel="bubbletip_comment_164">Erwin Brinkhuis</span> <span class="bUser-anonymous-tag">[Visitor]</span></dc:creator>
			<guid isPermaLink="false">c164@http://www.e-learn.nl/</guid>
			<description>Even een (ietwat lange en deels technische) reactie op het stukje over de leerkaart.

Toevoegen van tabellen in de Blackboard database schema&amp;#8217;s is volgens mij not done. Dit vervuilt het schema en kan in theorie tot problemen leiden bij upgrades e.d. zeker wanneer er ook constraints als bijvoorbeeld foreign keys worden aangebracht. Bovendien lijkt het mij dat dit niet toegestaan is vanuit de voorwaarden die Blackboard stelt. Moet de Blackboard database immers niet dedicated voor Blackboard zijn en blijven i.v.m. support e.d. Mogelijk dat zelfs een additioneel schema toevoegen niet is toegestaan.

Een additionele database opzetten kan natuurlijk wel, maar hoeft niet.

Tot nu toe hebben we in ons ontwerp nog geen restricties hoeven opleggen aan functionaliteit ten gevolge van het opslaan van leerkaarten in bestaande blackboard datastructuur. Dus een concrete aanleiding voor een additionele database is er niet.

Bovendien heeft het introduceren van een additionele database voor de inhoud van de leerkaart het neveneffect dat het opvoeren van de inhoud ook door het leertkaart building block gefaciliteerd moet worden. Door de Blackboard datastructuur te gebruiken, beschik je meteen ook over de benodigde schermen voor het opvoeren van de inhoud en hoef je die dus niet te bouwen.

Overigens wordt dezelfde manier van opslag ook gebruikt in de Course Organizer van de RUG. Tenminste, dat is wat ik opmaakte uit hun presentatie. Zij hanteren volgens mij alleen een additionele opslag voor een aantal kenmerken van de matrix.

Voor de leerkaart is een additionele database ook niet nodig vanwege het feit dat de leerkaart niet de gangbare building block architectuur van &amp;#8216;platte&amp;#8217; JSPs zal hebben, maar zal worden opgezet als een multi-tier webapplicatie. De leerkaart hanteert intern een Blackboard onafhankelijk datamodel. Dit betekent dat werkende binnen de leerkaart applicatie je je volledig kunt storten op de leerkaart zelf en in principe niets hoeft te weten van Blackboard. De leerkaart raakt slechts op 2 plaatsen de Blackboard specifieke zaken, namelijk,

1. In de onderste persistence-tier worden de gegevens opgehaald uit en opgeslagen in Blackboard. Hiervoor vindt dan eerst de benodigde transformatie plaats tussen het onhankelijke en het blackboard-specifiek datamodel. Grote voordeel is dat de leerkaart niet afhankelijk is van de daadwerkelijk opslag en er eenvoudig een alternatieve opslagfaciliteit kan worden ontwikkeld en &amp;#8216;ingehangen&amp;#8217; zonder dat dit impact heeft op de eigenlijke leerkaart. Dit betekent dus ook maximale onafhankelijkheid van Blackboard API versies en de mogelijkheid om op een zeer gelocaliseerde plaats eventuele problemen met een bepaalde API versie of veranderingen in een nieuwe API versie op te lossen.

2. In de bovenste presentation-tier wordt vanzelfsprekend de benodigde context als user en course aan Blackboard opgevraagd.

Op deze manier heeft elke laag zijn specifieke verantwoordelijkheden en lopen die niet door elkaar heen. Elk onderdeel heeft zijn specifieke focus op een afgeschermd aspect van de totale applicatie.

Mogelijk bepaalde aspecten van bovenstaande ontbraken in mijn presentatie, maar we wilden de presentatie niet te technisch maken.
</description>
			<content:encoded><![CDATA[Even een (ietwat lange en deels technische) reactie op het stukje over de leerkaart.

Toevoegen van tabellen in de Blackboard database schema&#8217;s is volgens mij not done. Dit vervuilt het schema en kan in theorie tot problemen leiden bij upgrades e.d. zeker wanneer er ook constraints als bijvoorbeeld foreign keys worden aangebracht. Bovendien lijkt het mij dat dit niet toegestaan is vanuit de voorwaarden die Blackboard stelt. Moet de Blackboard database immers niet dedicated voor Blackboard zijn en blijven i.v.m. support e.d. Mogelijk dat zelfs een additioneel schema toevoegen niet is toegestaan.

Een additionele database opzetten kan natuurlijk wel, maar hoeft niet.

Tot nu toe hebben we in ons ontwerp nog geen restricties hoeven opleggen aan functionaliteit ten gevolge van het opslaan van leerkaarten in bestaande blackboard datastructuur. Dus een concrete aanleiding voor een additionele database is er niet.

Bovendien heeft het introduceren van een additionele database voor de inhoud van de leerkaart het neveneffect dat het opvoeren van de inhoud ook door het leertkaart building block gefaciliteerd moet worden. Door de Blackboard datastructuur te gebruiken, beschik je meteen ook over de benodigde schermen voor het opvoeren van de inhoud en hoef je die dus niet te bouwen.

Overigens wordt dezelfde manier van opslag ook gebruikt in de Course Organizer van de RUG. Tenminste, dat is wat ik opmaakte uit hun presentatie. Zij hanteren volgens mij alleen een additionele opslag voor een aantal kenmerken van de matrix.

Voor de leerkaart is een additionele database ook niet nodig vanwege het feit dat de leerkaart niet de gangbare building block architectuur van &#8216;platte&#8217; JSPs zal hebben, maar zal worden opgezet als een multi-tier webapplicatie. De leerkaart hanteert intern een Blackboard onafhankelijk datamodel. Dit betekent dat werkende binnen de leerkaart applicatie je je volledig kunt storten op de leerkaart zelf en in principe niets hoeft te weten van Blackboard. De leerkaart raakt slechts op 2 plaatsen de Blackboard specifieke zaken, namelijk,

1. In de onderste persistence-tier worden de gegevens opgehaald uit en opgeslagen in Blackboard. Hiervoor vindt dan eerst de benodigde transformatie plaats tussen het onhankelijke en het blackboard-specifiek datamodel. Grote voordeel is dat de leerkaart niet afhankelijk is van de daadwerkelijk opslag en er eenvoudig een alternatieve opslagfaciliteit kan worden ontwikkeld en &#8216;ingehangen&#8217; zonder dat dit impact heeft op de eigenlijke leerkaart. Dit betekent dus ook maximale onafhankelijkheid van Blackboard API versies en de mogelijkheid om op een zeer gelocaliseerde plaats eventuele problemen met een bepaalde API versie of veranderingen in een nieuwe API versie op te lossen.

2. In de bovenste presentation-tier wordt vanzelfsprekend de benodigde context als user en course aan Blackboard opgevraagd.

Op deze manier heeft elke laag zijn specifieke verantwoordelijkheden en lopen die niet door elkaar heen. Elk onderdeel heeft zijn specifieke focus op een afgeschermd aspect van de totale applicatie.

Mogelijk bepaalde aspecten van bovenstaande ontbraken in mijn presentatie, maar we wilden de presentatie niet te technisch maken.
]]></content:encoded>
			<link>http://www.e-learn.nl/2007/03/30/2de_bb_buildingblock_ruilbeurs#c164</link>
		</item>
		<item>
			<title> Eduardo Hermsen [Visitor] in response to: 2de Blackboard building block ruilbeurs</title>
			<pubDate>Wed, 04 Apr 2007 14:32:22 +0000</pubDate>
			<dc:creator><span class="user anonymous" rel="bubbletip_comment_163">Eduardo Hermsen</span> <span class="bUser-anonymous-tag">[Visitor]</span></dc:creator>
			<guid isPermaLink="false">c163@http://www.e-learn.nl/</guid>
			<description>Het toevoegen van tabellen kan voorzover we nu weten niet binnen de door blackboard gestelde voorwaarden (maar we zoeken dit nog precies uit). Aangezien we een politieorganisatie zijn kunnen we dan ook niet om de voorwaarden heen. We stellen de Building Block vrij beschikbaar dus een ieder is vrij om verbeteringen toe te voegen. 
Leren&amp;amp;ICT, politieacademie
</description>
			<content:encoded><![CDATA[Het toevoegen van tabellen kan voorzover we nu weten niet binnen de door blackboard gestelde voorwaarden (maar we zoeken dit nog precies uit). Aangezien we een politieorganisatie zijn kunnen we dan ook niet om de voorwaarden heen. We stellen de Building Block vrij beschikbaar dus een ieder is vrij om verbeteringen toe te voegen. 
Leren&amp;ICT, politieacademie
]]></content:encoded>
			<link>http://www.e-learn.nl/2007/03/30/2de_bb_buildingblock_ruilbeurs#c163</link>
		</item>
		<item>
			<title> Gerwin Pols [Visitor] in response to: 2de Blackboard building block ruilbeurs</title>
			<pubDate>Fri, 30 Mar 2007 12:44:03 +0000</pubDate>
			<dc:creator><span class="user anonymous" rel="bubbletip_comment_160">Gerwin Pols</span> <span class="bUser-anonymous-tag">[Visitor]</span></dc:creator>
			<guid isPermaLink="false">c160@http://www.e-learn.nl/</guid>
			<description>Willem, toch handig zo&amp;#8217;n samenvatting. Jammer dat ik er niet bij kon zijn. Ik moet zeggen dat er inderdaad interessante Building Blocks zijn getoond (zeker die van de RUG). </description>
			<content:encoded><![CDATA[Willem, toch handig zo&#8217;n samenvatting. Jammer dat ik er niet bij kon zijn. Ik moet zeggen dat er inderdaad interessante Building Blocks zijn getoond (zeker die van de RUG). ]]></content:encoded>
			<link>http://www.e-learn.nl/2007/03/30/2de_bb_buildingblock_ruilbeurs#c160</link>
		</item>
			</channel>
</rss>
