October 17, 2002

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?

Tags: General
Posted by Fahim at 5:46 am   Comments (4)

4 Responses to

Subscribe to comments with RSS

#1
Gravatar Image
Duane Brosius 17 October 2002 at 3:36 am

WOW – I think I understand all of what you said. And that scares me. 😛

If you were to make a set of external variables for use at the next publish time then *I* think it would be rather easy (as compared to internal). So maybe we can two phase this. Try and get the external variables working in phase one and see what can be done for internal variables for phase two. I don’t have a clue as how to handle the timing issues that you bring up for internal variables unless the variables were date/time specific. Maybe rules based (some kind of table to define start/stop times for each keyword.) or the variable has the start date imbedded in it. (ie. ) Note: that the $BLOG name identifies Internal/External variable, an ID number (so you can have many) and a date start (optional) – in this case then you would code up your IVar001 data someplace and it would be placed in the BLOG journal when the date was correct. And I guess you could have an end date too.

The External variables could be done the same way – .

I am kind of leaning to the rules based version. The dates would be part of the data and not part of the keyword. You would enter the date(s) when you captured the data for the variable. and *I* said I thought it would be easy.

Well “gang” it was a thought – please add your ideas. 😛

-Duane-

#2
Gravatar Image
Tyran 17 October 2002 at 3:38 am

Scattered thoughts on the subject:

Sidebar variables could be demarcated using <$BlogSideBar> </$BlogSideBar> which takes care of Duane’s suggestion as all variables within <$BlogSideBar> </$BlogSideBar> could be static.

For the other variables (I’ll call them <$BlogVar> to keep them seperate from the SideBar items), I think you’ve hit somewhat of a show stopper with the publish order. The only obvious ways I can see around it is to base it on the most recent entry published. If the values are set via the most recent entry then show the value and if no value is set then remove the variable during publishing.

As for the Blogger import, definitely make it a seperate util as there’s no need for non-Blogger users (IOW, all your current users) to carry the extra weight if it were in the main app. Lines have to be drawn somewhere so that Blog doesn’t suffer the same fate as other software and become bloated with bells and whistles that only a very few want or need.

#3
Gravatar Image
Duane Brosius 17 October 2002 at 3:46 am

DUH – All my examples got removed because I put them in greater/less than signs.

sb: (ie. [$BLOGIVar00120021023]) and [$BLOGEVar002]

#4
Gravatar Image
monkiboi 17 October 2002 at 2:29 pm

instead of incorperating new things into blog you could have a plug-in system (like winamps) and users could download functions as required. it would keep the general file size down and allow others to write & contribute plug-ins allowing users to give something back. you might need to write an sdk though and i don’t know how much work that would be. just a thought though.

Leave a response

:mrgreen: :neutral: :twisted: :shock: :smile: :???: :cool: :evil: :grin: :oops: :razz: :roll: :wink: :cry: :eek: :lol: :mad: :sad: