As always, I have working on bildr a lot. But much of what I want to do is not possible with the applications I installed as the base (wiki forum and blog software). With RISDpedia, I modified the wiki software to make it to what I wanted, but it basically made it so I could never update, because it would undo everything I had done. With bildr, I am taking a new and different approach that has some really nice benefits, and one major problem.
With bildr, all modifications at this point are completely separate mini applications that are injected into the page. For instance the portal for bildr code is placed in the wiki with a single line.
<code project=”nameHere” />
This actually gets rendered into the page as
<script src=”http://bridge.bildr.org/tags/tags.php?title=ADJD-S371_Color_Sensor.js” type=”text/javascript”></script>
<script src=”http://code.bildr.org/nameHere.js” type=”text/javascript”></script>
The way the wiki software works, is it renders the meaning of all the wiki syntax, and stores it for later use so that it does not spend time re rendering the syntax, and can just use that pre rendered code.
In RISDpedia this had a major problem. If the information in that new inserted part cahnged, it would not be seen in the article until someone edited the page.
Now, because what is rendered is actually just a link, it is totally dynamic, so if the content is it pulling in is changed externally, the changes will appear as soon as they happen in the wiki.
This is also nice, because I am injecting changes, the core stays the same, and is completely upgradable without having to redo any changes.
The big downfall is that it is javascript. So if a user does not have it enabled, they cant even see it. But as I work more and more on bildr I think about this.
Browsers will just get more able and faster as time goes. So even though some of the requirements for experiencing bildr at its full potential (using CSS3 as well) are high, the browser will catch up.