I've worked out some of the Inklog kinks I encountered and things are back on track. The system will still be a full framework. However, I've made a decision that will drastically effect the future of Inklog. The system will require Smarty. In order to make a truly simple, flexible and usable system, certain features need to be present in the template system that powers it.
Like Movable Type's templates, all the display logic is present within the template file itself. This makes the system easier to use and provides the ultimate in flexibility. However, a link must be established between what modules perform their actions, and what template files are associated with those actions. This can be done in a separate location, therefore not relying on Smarty's flexibility, however, an additional complication comes into play.
Let's say that a user wishes to include into their template a standard side bar. This side bar is defined and formatted in a separate template file and is included whenever the user wishes to display that information. Now, let's say that this side bar requires information that the calling page doesn't need. For instance, let's say that main page is a simple blog entry, while the sidebar contains both a listing of the five most recent posts, and a list of categories. Without using Smarty, configuration information would be loaded to determine that the template required a particular blog entry to be loaded, however, that config file would have no knowledge of what was in the side bar template. So, unless the user accounted for the side bar's needs as well in the configuration for that template, it wouldn't have the needed data to display the side bar. And, while it would be easy for the user to account for such things, in the event that the use should change the sidebar, he must also change the configuration for every template that requested the sidebar. So, a better solution is to allow the sidebar to have its own configuration. This is where the trouble comes in. Every template system has its own syntax and the framework will have no way of knowing which templates are being included where unless it knows how an include is represented in that new system and preparses them to determine their requirements. This becomes very complex and resource intensive.
By requiring Smarty to be used, it is clear which templates any given template will require. Additionally, because Smarty is being used, we need not configure each template separately. The template can simply require the pieces it needs within itself.
We gain a few more things by requiring that Smarty be used. We can allow for caching of data to provide additional performance. We can also allow the format conversion routines to use Smarty. This allows for customization of the conversion on a node by node basis as well as the use of Smarty functions within those customizations. Additionally, formatting plugins can be written for use. If you want to be able to link to Amazon by simply typing {amazon isbn="1122334455667″} a plugin can be written and the plugin can be configured along with the nodes.
To conclude, Smarty makes it easier on me, easier on the user, and easier on those who wish to extend the system. Therefore, Smarty will be required as the templating engine, at least at the core level. If another template system is as featureful as Smarty, then I'm sure one could be dropped in place of another. Additionally, if a user REALLY wants to use another system, a Smarty plugin could be written that would simply call the other template system. In this fashion, minimal amounts of Smarty will be used.
