jump to article
...intermittent thoughts


Finally I got it. All my old posts in the Blogsphere template are now in this new database. Additionally I decided to change the design once more. Now we have a classical left hand navigation width a biger one right hand content area. The layout is highly scalable and flexible. Of couse I cannot claim to have it finished - there may be a lot more to do. Especially conformity issues could come up in the next days. I just started to migrate a layout into Dominoblog and did almost every testing with Firefox - maybe there are issues with Internet Explorer. Additionally I didn't use a validator at all - I'm sure there are smaller or bigger bugs inside :-)

At last and for me most important: how do you like the layout?

Blogsphere loosing content?

While migrating content from Blogsphere to DomBlog I had several documents with empty content fields. I know I had these articles finished, but now contents has disappeared - scary!

Blog Restarted

Yesterday I discovered the current DomBlog playground template version 3b1 in the net - and started playing around with it. I was (and am) excited, even if there's still something to do for a stable release. All over all I spontaneously decided to switch the system from Blogsphere to DomBlog!

measurable speed improvement

Later this day I had time to measure the speed improvement I got from my Blogsphere tunings last night. The result is quite impressive. While the untuned Blogsphere has response times of around 12500 ms per page the tuned version is around 3000. That sounds like an improvement of four times!!!

BlogSphere with complex RSS-Options

pew - I have it. just two hours of working and now my Blogsphere is not only valid RSS but even highly configurable at the feeds options:

Image:BlogSphere with complex RSS-Options


including the changes is not that hard but there are several design elements affected:
RSSConfig (SubForm) new Subform for all teh options - will be used in the configuration
Stories.xml | stories.rss (Page) The Header has become completely obsolete and is now just one computed Text, which is read from BlogSphere's Profile
comments.xml | comments.rss (Page) The Header has become completely obsolete and is now just one computed Text, which is read from BlogSphere's Profile
Blog Configuration | BlogConfig (Form) There's a new Tab which includes the RSSConfig-Subform

more speed to this blog

This server has been updated from Domino 6.0 RC2 to 6.5.1 - response times decreased significantly.

Avoiding replication conflicts in Blogsphere - part 2

Rocky Oliver has just provided some kind of Blogsphere official solution for avoiding replication conflicts within multiple replicas of Blogsphere. Looks like a similar way to my solution but is up to date to the latest release and a kind of official solution :-)

It took me one minute to save...

When saving a story in BlogSphere it took me around one minute to save it. A bit annoying to me but the fortune is it makes you work more accurate to prevent any unneccessary waiting for the save... ;-)

I had a look into the code behind and did some optimizations. I mainly put the calendar refresh into an agent which is called to run on server. Now all the agents work is not transferred over the network connection between client and server (and this is not really a low amount). By this way the Postsave event (which updates the calendar) takes only two seconds instead of 56 it was before on my network. By the way, Sundays are now displayed in the calendar in a different color - just for fun.

a bit of tuning

Blogsphere is great! I really like it, it is so easy to me to work with it - from now on, my personal Blogsphere will also work a bit faster - I reduced the number of uncached @DBLookups by 40 - there are still a lot of them in every page but these were simply unnecessary and are now gone to improve my very personal Blogsphere speed :-)

Fixing RSS

RSS in Version 1.2b1 of BlogSphere won't work anymore for several reasons - i have fixed it today for my blog and don't want to hold thet info in my backhand...

The reasons:
  • if you change the story date of a document, this doc will be saved with a date and no time information - the RSS-feed will be generated with an invalid UTC date format
  • that's also the reason, why the lastBuildDate token may be corrupted
  • after using mimeEntity.DecodeContent() in V1.2b1 the RSS-code is no longer in UTF-8 format - on my machine the format is ISO-8859-1

The Design Elements:

invoked Design-Elements are:
  • Page: "Stories.xml | stories.rss"
  • View: "RSS\Stories | RSS_Stories"
  • Form: "ClientStory | Story"

The fix:

Page: "Stories.xml | stories.rss"

1.        go to the Domino Designer
2.        open the Pages
3.        open the "Stories.xml | stories.rss" page
4.        go to the 1st line
5.        change the encoding of this page to an apopropriate value i.e. from to
6.        save the design page

View: "RSS\Stories | RSS_Stories"

1.        go to the Views
2.        open the "RSS\Stories | RSS_Stories" view
3.        go to the 2nd column
4.        replace the following line:
vTime := @Text(vDate;"S1T0");

by these two:
vTime2 := @Text(vDate;"S1T0");
vTime := @If (vTime2 = ""; "00:00:00"; vTime2);

5.        go to the third column
6.        replace the following Block:
vHour := @Right("0" + @Text(@Hour(vDate));2);
vMinute := @Right("0" + @Text(@Minute(vDate));2);
vSecond := @Right("0" + @Text(@Second(vDate));2);

by this one:
vHour2 := @Right("0" + @Text(@Hour(vDate));2);
vHour := @If ( vHour2 = "-1"; "00"; vHour2);
vMinute2 := @Right("0" + @Text(@Minute(vDate));2);
vMinute := @If ( vMinute2 = "-1"; "00"; vMinute2);
vSecond2 := @Right("0" + @Text(@Second(vDate));2);
vSecond := @If ( vSecond2 = "-1"; "00"; vSecond2);

7.        save the view

The RSS feed will work already, but until now only the symptoms have ben treatened, the reason is still untouched:
Form: "ClientStory | Story"

1.        go to the Forms
2.        open the "ClientStory | Story" form
3.        go to the StoryDate field
4.        rename it to "StoryDateInp"
5.        change the "DefaultValue" Formula to:
_date2 := @Date( Storydate );
_date := @If (@IsError( _date2 ); ""; _date2);
@If ( StoryDateInp != ""; StoryDateInp; _date != ""; Storydate; @Now)

6.        create a copy of this field, rename it to "StoryDate" and change the type to "Computed"
7.        change the datatype properties to display time values too
8.        hide the field fromNotes and web - it is unnecessary to be seen
9.        enter the following formula:
_baseVal := StoryDateInp;
@TextToTime (
@Text( @If ( @Date ( _baseVal ) = ""; @Date( @Today ); @Date ( _baseVal ) ) )
+ " " +
@Text ( @If ( @Hour (_baseVal) = -1 | @Minute (_baseVal) = -1 | @Minute (_baseVal) = -1; @Time(@Now);  @Time ( _baseVal ) ) )

10.        save the form

avoiding Replication conflicts in Blogsphere

I am replicating Blogsphere between two servers, and have had tons of replication conficts in it - now I know why - and have a fix for it

Well, there are some really useful agents in Blogsphere, which run on a schedule by 5 minutes basis. These agents are modifying the story documents in the database nearly every time they run and are set up to run on any server. So replication conflicts are preprogrammed:

How to fix it?
1.        go to the Domino Designer
2.        open the Agents
3.        open the "Update Stories Calendar" agent
4.        go to the agent properties window Image:avoiding Replication conflicts in Blogsphere
5.        go to the "Schedule" box
6.        change the "-Any Server-" entry to the server you run your BlogSphere on
7.        Save the agent
8.        do this for the "Update Story Response Count" too

minimizing replication traffic on BlogSphere

I recently had some remarks on two agents in Blogsphere - one of them can be fine tuned to reduce document saving and therefore replication overhead...

the second agent (Update Story Response Count) is a LotusScript agent, touches every story, allowed to have comments on every run - and this is every five minutes... I think it would be worth to have a look at this agent to avoid a saving of each of this documents on every run - besides, this may improve overall performance of BlogSphere:

replace the following lines:
  While Not doc Is Nothing

          Set doccoll = doc.Responses

          If Not doccoll Is Nothing Then

                  doc.children = doccoll.Count

                  doc.Save True,True

          End If

          Set doc = v.GetNextDocument(doc)


with these ones:

  While Not doc Is Nothing

          Set doccoll = doc.Responses

          If Not doccoll Is Nothing Then

                  If doc.hasitem ("Children") Then

                          If DocColl.count <> Clng( doc.children(0) ) Then doSave = True


                          doSave = True

                  End If

                  doc.children = DocColl.Count

                  If doSave Then doc.Save True,True

          End If

          Set doc = v.GetNextDocument(doc)



All over all I would prefer another solution for this agent:
1.        change this agent into a manually triggered agent
2.        create a scheduled simple agent to call the one from point 1 once a day
3.        create an agent running when new docs are created, calling also the agent from point 1

I think this will do the same but will increase the performance and decrease server load (which is surely not high at the moment but maybe high in two years after having thousands of docs in a BlogSphere instance) some more than only changng the code

note to myself: do not(!!!) use BlogSphere with an R5 Client...

Editing BlogSphere documents with R5 will make the contents disappear in a quite strange way - do not do this!

Blogsphere 1.2b1 released

have a look at it, test it, use it, comment it!

there's also an article on LotusGeek

Blogsphere Umlaut Problem-Fix

Messing around with BlogSphere, I recognized German umlauts are not displayed correctly. So I looked into the coding of the form and found a fix for it...

When playing with the current version 1.0.2 of BlogSphere, I saw strange display of German umlauts such as like an ü became an ü. Not really beatiful to me, since most of my articles will be in German unless my English becomes better .-)

So I had a look into the code and played with the LotusScript Debugger to find the reason. Well, I'm not really sure about my solution, since I never played with NotesMimeEntitiy class before, but it works to me now. Here's my solution:

There is a bunch of LotusScript code in the PostSave event of the "ClientStory" form, which creates the HTMLCode automatically. When debugging the objects I saw, some property called encoding and also saw the HTML text representation of my particular RichTextField. Well, that representation was not really beatuiful and had a lot of strange characters in it. So I looked into Designer Help (ey, what an idea .-) ) and found some function notesMimeEntity.Decode(). After putting this line into the code - the artikle was saved in a way, that worked even with German umlauts - simple but working!

Since there are two RichTextFields in the code, you have to add two lines into the PostSave interface code: Simply add a
       If Not mime Is Nothing Then Call mime.DecodeContent()
just after each occurence of:
       Set mime = item.GetMimeEntity
and the HTML-Code will be created with correct umlauts.


The fix was incomplete. There can be the case to have mor ethan one MimeEntity in one RichtextField, so you have to insert two more lines to the interface:
insert a Call child.DecodeContent() after each occurence of While Not(child Is Nothing), so these types of blog entries will be saved correctly too.