Based on prior and recent recommendations I have set up a Paypal account to accept donations to finance the development of the free version of LotusScript.doc version 2. All donations will be very much appreciated and help me justify the time I put into this.
As of today the (new) XML output format of LotusScript.doc is done and I’m starting on the HTML output format on Saturday. Maybe Friday night.
Eclipse.org is doing a series of training series around the world for further development using the Eclipse rich client platform (RCP). They’re doing introductory courses and advanced sessions so if you’re looking to start developing for the Notes 8 platform check it out.
This morning, very very early morning, I finally submitted my abstracts for Lotusphere 2009. Two sessions on plugin development and one on developing custom blackboxes for the Sametime business card system. In both plugin sessions I will demonstrate and tell what I have learned developing plugins for the Notes 8 client – both from TwitNotes and my commercial plugins for my company. The Sametime session will be an extension on the similar sessions I have held at a number of Danish user groups. It goes without saying that all three sessions should be accepted… 🙂
If I could have it my way both plugin sessions should of cause be accepted and run like 101 and 201 style classes with the former being an introductory session and the latter a more in-depth session. An alternative would have been to go for a JumpStart but that seems to be more “This is how you do Java” or “This is what DWA is all about” type sessions. If you think I’m wrong please let me know and I’ll write up another abstract – I’m in no way shy!
I’m crossing all I got…
Simple, powerful and easy to use XPath extension for Firefox to easily work with XPath statements: XPather.
Based on prior and recent recommendations I have set up a Paypal account to accept donations to finance the development of the free version of LotusScript.doc version 2. All donations will be very much appreciated and help me justify the time I put into this.
As promised earlier in the week I have been spending the weekend behind the keyboard working on LotusScript.doc version 2. While the weekend started with a lot of grief and unraveling Subversion merge conflicts I am now quite a lot further. The reason the my grief was that I started working on the LotusScript.doc codebase in my Eclipse 3.2 workspace whereas the latest code was in my Eclipse 3.3 workspace. So after resolving conflicts after an update, I moved the code into Eclipse 3.3 where I’m working now. The plan was to go to Eclipse 3.4 but that has to wait.
God thing I’m using Subversion for my code!
As of now (Sunday night) I’m happy to say that the major parsing is done and the engine looks very sound. I have to spend a little more time on tags (e.g. @param, @return) that span multiple lines in comments. The good news is that inline tags is done (e.g. {@link db.form PersonForm}). I also have the XML output almost done and I have started on the HTML output using Jakarta Velocity templates to allow you to change these if need be.
If you’re interested you can see the XML output I just generated here (around 1 MB).
Performance using Java is in stark contrast to parsing LotusScript. A full parse of the LotusScript.doc v.1 documentation center database (incl. the entire LotusScript.doc v.1 codebase in LotusScript) takes around 3 seconds on my laptop running the code from Eclipse. I can’t remember how long it took to parse the database with LotusScript.doc v.1 but I seem to remember it was much longer. Very nice… 🙂
In my post titled “XPD – where do you live?” from the other day I discussed some problems with i18n (internationalisation) of applications developed in Java for the Notes 8+ platform using the built-in classes (java.util.Locale). Since that post I have been in dialog with IBM via the Domino NEXT Design Partner program.
It has been confirmed that this is indeed a problem and probably in the core Notes client. The problem probably stems from Lotus Expeditor.
Unfortunately not much light has been shed on the subject except IBM asking me to run a Danish Notes client which is among the worst thing I could imagine doing. I run software in English – period! I do however expect the software I run to be able to detect my computer locale as set in the operating system. As an aside it is actually quite common for non-English speaking Europeans to run English software despite the fact that a native-language edition is available.
As part of this process I have been thinking about the API’s that we need to have available for i18n. It is quite clear that we need
If we had these we should be able to create the kinds of localized products and plugins customers expect and demand.
What is your take? Can you see more API’s we need while we’re at it?
Sean Burgess is running a blog on Lotus Foundations over at asnddesigns.com: Foundations for SMB
“Selected IBM Lotus products and Program Services will be extended. The following product releases licensed under the IBM International Program License Agreement will be extended to April 22, 2010. The previously announced product withdrawal date was April 23, 2009.”
So, inspired by many kind e-mails of encouragement, I’m restarting the development of LotusScript.doc v.2 (once again). The main difference is that this time I have actually set aside some time for the development during the weeekend and sent my girl friend off to Barcelona to avoid being disturbed… 🙂
Based on prior and recent recommendations I have also set up a place to donate money to finance my development of the free version of LotusScript.doc version 2. Any donations will be very much appreciated to justify the time I put into this.
Look forward to an update during the weekend.
Disclaimer: I’m trying to get some info from IBM on this subject so please check back as I will update this post as more info becomes available…
Again this is one of those posts that will annoy the heck out of European developers…
Internationalisation – or i18n – is done using the java.util.Locale class in Java. When calling Locale.getDefault() the standard Locale for the JVM should be returned and should be da_DK for me (country: Denmark, language: Danish), en_US for you US guys (country: USA, language: English) and de_AT for people from Austria (Country: Austria, language: German). The Locale can be supplied to many localisation sensitive classes such as java.util.Calendar etc. to make sure it works as expected for the current user locale. Most times however you don’t supply the locale explicitly which will make the platform do a Locale.getDefault() for the current locale.
Meet Lotus Notes 8+…
Per default Lotus Notes 8+ runs with a Locale of en_US which is great if you’re based in the USA and speak English or simply only use the built-in functionality of Lotus Notes. If you’re a plugin developer and you do any i18n work you will be sadly disappointed since Calendar and ResouceBundle will be broken. Since Locale.getDefault() returns en_US you will get back a Calendar for the US (e.g. Sunday is first day of the week) and English strings from your resource bundles.
Maybe this is why the preference has a page for locale setup (see File/Preferences/Calendar and To Do/Regional Settings) which is used by Mail.
To makes matters worse I think it’s a core platform issue since you can actually change the language of your Notes client by supplying a command line argument (-nl) to the Notes client. Doing this (-nl da / -nl da_DK) changes the menu item text in my Notes client but any plugin that use Locale.getDefault() still return an incorrect result as shown on the image below.
To make it even weirder it works as expected when the Notes client is started from the Eclipse IDE using “-nl da_DK”. Go figure!
(click on the image for larger version)
This behavior has been verified with Notes 8.0.1, Notes 8.0.2 and Notes 8.5 beta 2.