I had been giving the idea of customizable sidebars suggested by Duane a lot of thought since it kind of dovetailed into another idea suggested by Gene Arnold who wanted user definable variables that could be inserted anywhere in a template. The user can define default values for these variables or keep them blank and during publishing, if an variable was referenced and it had a value, it would be displayed, otherwise the variable tag will be removed from the template. Further to this, the journal entry itself was supposed to have new values for the variables defined at the top and any values defined in an entry replace the static value pre-defined for that variable (if any). Now, I heard from Duane yesterday and he further explained his idea and said that the main reason he wanted the variables was so that somebody could update their sidebar via e-mail by specifying the value for the sidebar variable – basically, allowing remote journal management without having to deal with the template at all.
Of course, as far as I understood it, Gene wanted the variable system for the Blog section where the entries are displayed so that he could have variable values in the template on a per-entry basis whereas Duane wants the variables outside the Blog section – basically the variables have to function as both internal and external Blog tags. Currently, since there is a clear demarcation between the external and internal Blog tags, I parse them separately. If the Blog variables could be in either section, the coding is going to present some problems – as well as the logic. For instance, when a static variable value is replaced by a new variable definition in an entry, is the new value permanent or is it just for the duration of that Blog session? I would say permanent thinking about Duane’s needs but if we come back to Gene’s needs, that might cause a problem unless the user remembers to “wipe” the variable value when he wants that variable to be empty – or rather, he will always have to define the empty variables in his entries (if they are in his template) because the variable might have been filled in an earlier post. DId that make any sense to anybody? :p
While the idea has a lot of merit and could lead to a lot of innovation with Blog, it is going to be fairly difficult to implement in a way that it would work across the board. Yes, we can come up with the framework easily enough but what I’m worried about is the coding and the performance – especially if the variables can be both external and internal. There is another problem with defining variable values in entries – when does it have effect? What I mean is, that if variables substitution is going to be static, then any new entry has to replace the existing value, right? But at what point do you decide that the new entry’s value is going to substitute the existing value? At publish time? If so, then older entries with the same variable might substitute a newer variable value if you publish your journal in reverse order since the last entry to be parsed will be the oldest one. Yes, I know it might be a bit hard to grasp what I’m talking about here since I’m trying to explain something in my head and you might have no idea what I’m talking about …
Anyway, what it comes down to is that there is a fair bit of groundwork to be covered before we can come up with a working system but I think it should be done since it will allow greater flexibility with Blog. Speaking of flexibility, I’m also looking into allowing the importation of Blogger entries into Blog for those of you who want to switch However, since that is a one time operation, I am not so sure that I should bundle that functionality into Blog itself. I’m always conscious of application size and am reluctant to increase it unless absolutely necessary. So at the moment, I’m thinking of keeping the Blogger importer a separate application that a user can utilize if they are thinking of coming over to Blog. What do you think?