I was in the middle of writing this arm-length article on why you should know XML and XSLT... and realized that I was well onto writing a book on the subject. Wanting to get the point across, here's the highlights on "Why you should know XML and XSLT as a Domino and Lotus Notes Client developer":

First, the more "in general" thoughts:

• Everything that you see in your Browser is logic-driven content.
• Content consists of either resources or markup.
• Markup is text.

XML, which is nothing more than structured text, can be translated on-the-fly via XSLT into anything that is "text"-based - HTML, XHTML, JavaScript, CSS, ... etc., so let's keep that in mind.

Now for something more Domino/Lotus Notes Client friendly:

• DXL is here and readily available to us Domino Web and Lotus Notes Client developers. (Sure, still not complete, but for NotesDocument management...)
• XML, XSLT, and DXL can all be combined (DXL is simply XML after all) to make some pretty amazing advances in both Domino Web and Lotus Notes Client development.
• With XPages possibly alleviating most of the hacks we rely on today for Domino Web Development (and eventually Lotus Notes Client Development), the more flexible and separate from application UI we store and maintain our data, the more "forward-ready" we are when we are presented with new presentation technologies and capabilities.
• Everything changes - RAD today is not going to be RAD tomorrow. If we do a little more architecture work up-front today to align with the RAD of Tomorrow... hell, you could wizard-build applications, Domino data stores, etc. en masse.

If you take only one thing away from this post, be it that the conventional way we all develop applications is changing - evolving - and we're finally on the way to getting what we've always wanted out of the platform: control.

Yesterday I tried something different (for me anyways): I published a quick demo of something that I'm cooking up using the Microsft Web Browser Object Control that I've been talking about these last few days. The difference with yesterday's demo was, instead of using simple images trying to show you what I was talking about, I used Jing and posted two Flash screencasts.

Now, the embedding was totally screwy, but I think that by using these screencasts I was able to quite effectively communicate what I was doing in less than a minute. More importantly, the prep work involved was around five minutes from the start of the recording to it's publication (while Jing limits you to 5 minute videos, it's a pretty slick little application).

But I'm not too sure - were the Flash demos as effective as I am assuming? What were your thoughts with the screencast? Should I have included a voiceover?

Data Store Architecture - sounds pretty scary doesn't it? You get these horrific visions of server rooms and SANs across WANs... when it's something that every single Domino Developer does on every single application that they work on. At least they often start with Data Store Architecture. Don't believe me? That's okay - maybe by the end of this article however you'll see things my way...

One of the first things that I (and I believe many of us developers) do when getting started on a project is to sit down and Napkin-Develop the overall solution. It's this initial blueprinting of the application where we should be working on the Data Store Architecture - at least at a first pass. And some of us do! We say "oh, we'll need a username field here....", etc.

The problem is that this is where the vast majority of the Domino Developers out there take their first mistep: they launch the Designer Client, create a new Form Design Element, and put a Field element called username on their Form.

What's wrong with this? Nothing... if you're not separating your UI from your Data. You're sticking to everyday Domino Development, you're right on-par with the rest. You decide whether that's a good thing or not...

What I do as of late, is to continue with the blueprinting phase of the application. I work out, often through pseudocode, my Data Store Architecture. I define the elements that I will need to track specific to the type of record that I am storing. I define the content type of the given element. I track the individual requirement, lbound, and ubound for the given element (do I need it, is it multi-value, etc.).

I map out what all of my requirements are in the application, all of the potential integration points with existing solutions may be, and I do so before I even look at a development IDE.

And I do this, which might seem like overkill to a lot of you out there, for what I think is a good reason. - so bare with me here...

I'll illustrate my point by hijacking my own article here - let's take a look at the ATOM APP entryType Schema. This is an open standard schema that, for the sake of this article, we'll say is exactly in-line with what we're developing.

 <xs:complexType name="entryType">
  <xs:annotation>
   <xs:documentation>
    The Atom entry construct is defined in section 4.1.2 of the format spec.
   </xs:documentation>
  </xs:annotation>
  <xs:choice maxOccurs="unbounded">
   <xs:element name="author" type="atom:personType" minOccurs="0" maxOccurs="unbounded" />
   <xs:element name="category" type="atom:categoryType" minOccurs="0" maxOccurs="unbounded" />
   <xs:element name="content" type="atom:contentType" minOccurs="0" maxOccurs="1" />
   <xs:element name="contributor" type="atom:personType" minOccurs="0" maxOccurs="unbounded" />
   <xs:element name="id" type="atom:idType" minOccurs="1" maxOccurs="1" />
   <xs:element name="link" type="atom:linkType" minOccurs="0" maxOccurs="unbounded" />
   <xs:element name="published" type="atom:dateTimeType" minOccurs="0" maxOccurs="1" />
   <xs:element name="rights" type="atom:textType" minOccurs="0" maxOccurs="1" />
   <xs:element name="source" type="atom:textType" minOccurs="0" maxOccurs="1" />
   <xs:element name="summary" type="atom:textType" minOccurs="0" maxOccurs="1" />
   <xs:element name="title" type="atom:textType" minOccurs="1" maxOccurs="1" />
   <xs:element name="updated" type="atom:dateTimeType" minOccurs="1" maxOccurs="1" />
   <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
  </xs:choice>
  <xs:attributeGroup ref="atom:commonAttributes"/>
 </xs:complexType>


A few things should jump out at you here, even if you're not familiar with the schema:

1. minOccurs="1" - read: "Required Fields"
2. maxOccurs="unbounded" - read: multi-value data elements
3. type="atom:..." - these are defined throughout the schema in XML, allowing us to know exactly what we're in for...

Now, imagine this. You need to write a front-end for an application that's utilizing the ATOM APP entryType schema. From those 20-something lines above, you have an immediate grasp on what is needed for the application to function as-intended. Your UI becomes a variable - it's sole purpose to facilitate the user's proper data entry by whatever means you have available to you.

I don't know about you, but I see this as an empowering and completely sure-footed approach to solution development!

So let's jump back to the world of Domino Development, and our blueprinting... what's stopping me from taking on this same approach? Instead of jumping directly into the Domino Designer client, I instead open up my favorite XML editor - say Aptana - and begin writing out my data store architecture in XML schema. Based on all of the blueprinting and pseudocoding, I should have a really good grasp on it at this point. What I don't have, I'll fill in as needed - but I'm doing this without playing around within a Domino Developer client where I may be distracted in thinking that the pixel-spacing for the name picker for username is off...

And at this point, why should I worry about the UI - I've architected my data store now completely independant of UI - I can literally create a UI in any technology I wish as long as it can communicate back to my application. To do that, we'll need a message broker - which is the subject matter for another (upcoming) article - but the point still stands: once you effectively separate the user interface from your data store architecture, anything is possible.

I'll leave this intro if you will with a few final thoughts:

1. Imagine having such an XML-based schema document for your applications.
2. Imagine needing to modify that application for whichever reason in 6 months to 1 year - and having that XML-based schema document.
3. Imagine walking into a project cold, but being presented with such a schema document.
4. Now, imagine if DXL was full-fidelity!

It was brilliant. I had commented a book on yesterday's post topic, and it was the stuff of legend. In it, I explained the following (watered down and from memory):

1. I didn't want to replace documents as the Notes data store, per se.
2. I DID want to implement a translation layer between the UI and the data store, thus separating the data store.
3. This translation layer/data store separation architecture would allow us to maintain individual or multiple documents in external databases, as well as potentially update other data stores. Imagine you fill out a simple form and on submission I'm updating 5 different Notes applications as well as an XML file that's used by an ancilarry technology.
4. The translation layer engine could be written to allow all of the business logic to be defined via configuration documents - allowing not only user control but also allowing us to "skin" like applications.

I mean it was poetry. It was insightful. It was brillaint. IT GOT ATED!

I'm saying that "my dog blog ate my homework brilliantly written comment", and I've had enough. I'm sick of this weblog template - written by yours truly, gang - and this was the last straw!

So I'm going to be writing a new blog template from the ground-up. Ctrl+N and I'm off.

Now, before anyone asks me why I'm not using <enter Domino blog template here>, I'll give you the honest answer. I think that the blog templates are great! They provide people with a quick-to-deploy solution that allows anyone to blog within moments. As a developer though, I cannot tell you HOW INVALUABLE it was to me to write my own. It's purely the development exercises involved in creating a blogging template that I'm interested in - it allows me to keep my skills sharp while integrating 3rd-party technologies and solutions that I honestly wouldn't see in "my day job". That's why I originally wrote my own (although that's not true, when I started this site there wasn't such templates lying around and available - you kids with your baggy pants and new fangled IBM blog templates have it easy... Now get off my lawn!), and that's why I'll continue to writing my own.

So, that being said, is there anything that people would like to see here that isn't already? Co-Comment was one suggestion. Anything else? I'm open to any suggestions at this point... but here's a few things that I'd like to do:

• Co-Comment
• Authenticated Comments - something maybe OpenID-based...
• Polls
• Good ol' Email Notifications/Newsletters
• (maybe) Threaded Comments

Add your request/suggestion onto the pile - and I'll be as public as appropriate (I won't want to bore everyone) with the development effort.

Twelve (12) comments and countless emails and IMs later, it appears as though the vast majority of the Notes Shops out there are working in the Lotus Notes client! Makes sense, as the Lotus Notes client offers many built-in functionality and certain capabilities that other clients (web browser and mobile clients) either don't exactly offer or offer at the cost of a large development undertaking. So, from what I got out of my little poll (wonder if I should build a simple poll widget on this site - I enjoyed the feedback but the offline comments were much more interesting; maybe people just don't want to publically comment?!) was that the Lotus Notes client is delivering more than the slight majority of solutions. And while Domino Web Development is a great thing, and AJAX-infused DHTML-based UIs are not only good investments but also really really cool... it still doesn't resolve what I feel is the biggest crutch for the Lotus Notes client - it's struggle to integrate the very technologies that would make the Lotus Notes client appear far less archiac that it currently does.

So how can we, the quick-to-adopt "innovative" developers truly provide innovative solutions for our Lotus Notes client development projects?

While furthering a module in our Revolution CRM solution (Dashboard - a portal-like central hub for our various modules), I was tasked with the need to provide users with various meta-data reporting capabilities. With ND7, while I was given certain built-in functionality, nothing really jumped out at me as a fully functional widget-izable solution - I needing something that would visually display a large amount of representative data from our various solutions while doing so with small-footstep requirements in mind. If this was for a Web browser client application, I would use something like Flash or SVG... but this was the Lotus Notes client! Could I get a solution, such as Flash, to not only work within the Lotus Notes client, but provide interaction capabilities? Could I feed it data from my various sources? Could I allow the user to interact with said data?!

The fact that I'm currently writing an article that showcases exactly what I did (with the help of Mark) should tell you that I was successful in integrating Mark's solution along with my own and some 3rd-party XML-fed Flash charts and graphs.

This was pretty darned "innovative" if you ask me. Mark's solution is an excellent example of taking Lotus Notes client development to the next level. It's simple approach allowed me to create a widget-ized, XML-fed, configurable and thus totally dynamic and interactive Flash-based charting and graphing engine for Dashboard. Unlike some Lotus Notes client-based CRM solutions that show a picture of a static chart (ahem!), Revolution CRM now has the fully-functional solution in code-review!

Now, aside from what may appear to be a commercial for our products, it leads me to my main point of this entry: I think that while AJAX is a cool thing, 50 websites with top-level Domino developers showcasing their spin on it's implementation does not help the everyday, Lotus Notes client-focused "Notes shop" developers (especially since IBM won't send them a non-Sales SWAT team as per my recommendations - ahem! x 2 ). We need to further Lotus Notes client development efforts to reach these people.

So it's with that said that I'll not only deliver my next article, which outlines step-by-step instructions to show you how I adopted Mark's excellent solution and rolled it into an integrated, interactive Flash-based reporting engine... but I will also make every effort to showcase more Lotus Notes client development innovations either as I come across them or (with all humility foresaken) as we make them ourselves!

Oh... and one last thing: While the above linked article "is an excellent example of taking Lotus Notes client development to the next level" - Mark's utilization of the embedded Flash Reader control is also an excellent example of the lack of documentation that really hurts the Lotus Notes client developer that wants to use the tools that are available to them! If there's documentation on all of the properties, attributes, and their usage out there that I'm missing... please correct me and point me in that direction!