January 15, 2008.
Just a quick heads up that a backwards incompatable change has been made in the LifeFlow SVN.
Up to this point to access the file stored in a Resource file you had to complete two steps:
Now instead you will simply write
[name of your resource][f name_you_gave_it]
Keep in mind that you won't have to make any changes to entries written in the previous style unless you save them again. If you leave them as they are, they won't rerender until you rerender them by manually saving them. So, to the extent possible, just write new entries in the new style, and leave old entries untouched.
Early on I had the idea to dynamically associate resources with blog entries and to dynamically generate Markdown references for those associated resources. This was the foundation from which Dynamic Blog Context was born.
Unfortunately this concept required that the Entry have an intimate knowledge of the Resource instances that were associated with it. This is less trivial than it seems, because the ManyToMany relationships are not created until the object finishes saving to the database. This means that the Entry needed to save before it could render itself correctly, and rendering itself was part of saving. A bit of a circle, one might say.
Thus the work around for the awkward circle is to save once to establish the ManyToMany relationships, and to save again a few seconds afterwards to finish up the rendering (with some logic to prevent an infinite save loop from occuring).
Transitioning to the new Dynamic Blog Context based solution removes this particular need for the awkward and ugly double save. For the moment the double save is still in existance, because a few pieces of DBC do require up to date knowledge about the ManyToMany relationships an Entry is in (for example, to generate a link to the first entry in a series the Entry is in, you need to know what series it is in).
However, the double save is slowly being phased out, and will be completely removed once that is possible without a loss of functionality.