Ideally, I prefer Tim's method, which I've used in the past actually to great success before wanting to render the NotesItems in the UI via Fields or Computed Text. The querystring GET for a NotesDocument lends itself to more of an API-based architecture... which in this world of "I want this to work with that" technology requirements, is where we should all be pushing our applications. So about mid-way through this conversation it hit me - there's no single-place authoratative W3C-like committee/community effort that talks to today's development standards, tomorrow's "this is what's coming up", and (maybe most importantly) deprecated practices.

Is this what the IBM Domino Web Development Best Practices RedWiki was supposed to be? I dunno... maybe I'm just hoping for too much here - but I think this community could take on the challenge of creating (and maintaining) an IBM Lotus Notes and Domino Development... something - Best Practices Guide?, Standards Body?, .... yeah, I don't know what you'd call it, but you get the idea.

I would think that this could be easily done: take IdeaJam, DominoWiki, host them on the BleedYellow network, and have a community-voted board to oversee what is ultimately a community effort.

Am I the only one who wants such a defined standard? Am I being a foolish optimist here in thinking that this can be done?

I love challenges when it comes to code. Tell me it can't be done, and I take that as a personal attack and will do everything that I can do prove you - naysayer of all things great and truthy - are wrong.

My biggest problem is... once I've proven that it can be done to myself, I get bored really quick... and I tend to walk away.

The thing is... I don't even have to write it to get my apathy up about something - once I figure it out in my head I'm often already moving on... which is not good.

This results in the quiet death of a lot of some really cool things, and I'm going to try - really put in an effort - to correct this particular character flaw that I see in myself.

To start, I've published 2 downloadable examples recently: SOTU - Remote Console Reporting v0.1 and Sorting Hat v0.1 - both of these simple applications (that admittedly aren't ground-breaking or amazing per se but have their charms) are both available for download... and I will try my best to keep up with them.

This was the first step - the second... well, I don't want to say anything that might wind up not getting done, so I'll just keep a tight lip until I have something a little more concrete to show you.

Please Note: There are two (2) "document" Form Design Elements - the hidden "document" showing the initial demo displaying two (2) Microsoft Web Browser Embedded Object Controls and allows Drag-and-Drop between them. The active "document" is used to maintain a full-screen File Browser; it's URL calculated in the "url" NotesItem, which uses the "filestorebrowser" Form Design Element for UI presentation.

For an added bonus, check out the About tab!

Feedback and suggestions are always welcome!

Thanks,

-Chris

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.

Tim explains what this simple-yet-powerful application does... but there's something that you get for the measly $9.99USD (and that's like 2 1/2 EURO with the current exchange rate?!) that Tim doesn't really get into in the product write-up:

Simply put, you get a fully functional application, written by one of the best in the business, showcasing how SIMPLE combinations of industry-standard technologies, Lotus Notes RAD, Java, and some other tools that are in all of our arsenals can address everyday business needs. The $9.99USD gets you the source code for JSFactory. For a price that's 1/3 the cost of most of the books on the subject, you're getting something that you can rip apart, dissect, and see how someone else - that's proven himself time-and-time again - gets the job done.

So, personal relationships aside (I can't stand Tim... <cough>prick</cough>), I can't recommend more getting yourself over to the JSFactory site, plunking down that whopping $9.99USD, and soak in the simplicity of genius.

I honestly don't know how an "end user" is supposed to do this sidebar widget adding (IBM - see how Google does it from iGoogle for a "how-to"), but I created a more simplified version of the "wizard" and added it as a Sidebar Widget - and for a first run I'm happy with the results:

Click the screen-capture below to see a full-screen Flash Demo of the SOTU Sidebar in action!

I've added this form to the v0.2 release of SOTU and will probably continue to improve both the Sidebar and the application itself. I've heard some great feedback and suggestions on this simple-yet-useful application, but always interested in hearing more. If you like it, or have a suggestion on a way to improve it - leave me a comment!

Currently at v0.1, SOTU allows you to run Remote Console Commands against a defined selection of servers and tracks the responses to these commands for review. This release took me about 6 hours from Napkin-Development to creating the attached Zip file total development time.

I'll continue maintenance on this application based on feedback received, so if there's something that you'd like to see in there, please let me know!

For our first post, I'd suggest a look at the Primer section of the Domino Web Application Development Wiki - something that I was very adamant that make it into the RedWiki in the first place.

This section, broken down further into individual technologies and principals, will give you an introduction and overview to the various tools that you will weild as a Domino Web Developer: HTML, Java, JavaScript, Styles and CSS, Web 2.0, Web Services, Web Standards, XML, XSL, and XSLT!

It's an intro, but I'm certain that it will open the eyes of novice Domino Web Developers as well as prove a quick review for us "old hands" - in fact, the XSLT work discussed there will eventually become a huge part of Project Broker!

In the next post, we'll discuss the initial architecture of a simple Domino Web application.

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?

View demo in full screen.

In this first really simple demo - we can see the embedded Microsoft Web Browser control, which is "activated" in the PostOpen event on the UI Form Design Element and uses the value stored in the url NotesItem of the NotesDocument. This allows us to not only access remotely-accessible file stores directly from a Lotus Notes client UI, but also allows drag-and-drop from this "widget" into the UI document - pretty slick!

View demo in full screen.

In this (yet again really simple) demo - we can see two embedded Microsoft Web Browser controls, again "activated" in the PostOpen event on the UI Form Design Element and that each use their own NotesItem from the NotesDocument for it's control (url and url2 respectively). The big difference in this example, you can drag-and-drop from one "widget" to another "widget" to move files across remote file stores - really slick!

Now, there are some issues with this approach that I'll get into in the next few days - the biggest being that the UI Document needs to be in Edit mode from what I can tell to run the Microsoft Web Browser control. I'm working around that stuff now and expect to have this example database available for download pretty soon!

Comment here with suggestions, thoughts, comments, and things that you want to see!

After some questions, I found that the customer was asking for a "document library" because they wanted to track specific drawings against specific projects and other categorizations that the standard File Store architecture would no longer facilitate. They wanted to be able to apply category labels to grouped files. All things that you'd want to do in a typical "document library" - but I again didn't want to store these large files in Domino. So I thought about using some sort of embedded, programaticaly-accessible Windows Explorer widget - which would allow me to display the "linked" documents, while storing the labeling information on the actual "container" UI document. Simple enough right? Now to just find a Windows Explorer widget... that I could modify within the Lotus Notes client container... in release 6.5.

Got some good feedback from people via my Twittering the question (thanks Steve and Andrei!!!) but me being the stubborn me, there had to be a simple way of doing it... and possibly with the Microsoft Web Browser Control (which was the closest thing that I could find to a Windows Explorer Object). So I googled "Microsoft Web Browser Object" + Lotus Notes...

Now, I should have known that...

1. I was getting the idea that this was possible from somewhere.
2. That someone like Tommy Valand would already have done it!

The good news? Well, using this approach, I was able to give my customer a quick-since-it-was-already-written solution:

I simply modified their current "project" Form Design Element and added (on a new tab called File Resources) a field called url and am embedded Microsoft Web Browser Object (Control).

Pretty simple right? Yeah - the only this that was missing was the logic to control the embedded object - which I added to the PostOpen event:

Sub Postopen(Source As Notesuidocument)

 Dim browser As Variant
 Set browser = source.GetObject("Microsoft Web Browser")

 If (Len(Source.FieldGetText("url")) > 0) Then

  If (browser.width <> 400) Then
   browser.width = 400
   browser.height = 400
  End If

  Call browser.navigate(Source.FieldGetText("url"))

 End If

End Sub

So pretty basic stuff all around - when the "project" document is opened, I check to see if there's a value defined in the url field. If so, launch my embedded "File Browser" of sorts and show the contents!

If there's an interest in having an example of this "approach", let me know and I'll put one out here.

So I put said widget on this site within about 2 minutes so that you, Constant Reader, can IM me should you feel so inclined without having to initially add me to your given Contact List. I await the anonymous "you suck, fattie!" with baited breath...

All kidding aside, if the "one [client] to [access] them all" and this widget weren't enough... the UI is UBER slick. Okay, I'll elaborate because I think that this is where the client stands apart from anything that I've seen in the past. Sure, when minimized most clients give UI Prompt notifications of various activity - we've all seen that before. What I think really differs the Digsby client from other clients I've used is, on IMs, you have the ability to immediately respond to said IM as they've included an input element in the Notification! Did I not tell you that this client has a brilliant UI?!

Me too Tim, me too...

I plan on putting this thing through the paces over the next few days. I'm going to try and test out the GTalk VOIP feature within this client sometime today with Tim when we work on getting another episode out to our 3 subscribers, and will report back my findings. From what I've seen so far, I'm ready to uninstall Gtalk/Gizmo/GAIM/....

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!

Obviously, this is spam. And while I'm used to getting IM spam on AIM and YIM, this is the first time that it happened to me via Skype! Be warned!

...via Adam Curry's Daily Source Code - thought it was worth a share! Check out Skinnie Jones here!

Tim is going to head up the really difficult part: another attempt at the servlet handling the HTTP Method PUT and DELETE verbs.

Me? I'm currently working through the cloud of prescription medication to architect the Domino data store. And here's what I have so far:

1. Complete separation of client UI and data.
2. Treating the Domino database as an XML data store.
3. Utilizing XSLT for content rendering of XML data.

So, here's what we're basically looking to do:

Let's say we're using APP for our CMS engine for a particular client type - something either 3rd party (like ScribeFire let's say) or web based. Instead of directly calling a feed via (what most of us do today) a View Design Element or a NotesDocument via it's URI, we're going to utilize our servlet as a message broker to communicate with the back-end data store - in this case, Domino. Now, as mentioned, since I'm going to utilize APP, I'm going to need an ATOM-based XML feed for my data. Simple enough right? I could do that in the Designer Client with ease. What if I want to then - based on a future requirement - utilize another 3rd party solution that utilizes Web Services or XML-RPC for it's CMS client technology, I'm going to have to write from scratch a web services consumer - which would suck, as I'd need to crack open the Designer client each time. And each time I would do this, I would need to create a new View Design Element, a new Form Design Element (or a few maybe), and a whole slew of other Design Elements - all to support just-another-entry-point. Kinda silly huh?

Now, imagine if you will that the servlet message broker was designed to not only consume requests - be they RESTful, XML-RPC, or pick-your-poison - communicate said requests to the back-end data store (Domino), and respond as required for the given functional need. Pretty slick. Now, imagine if that was all configuration-based and thus "skin-able". You'd have the ability to support a new entry point into your solution - be it a CMS or content reader of choice - by simply enabling some configuration/control documents.

To do this, we're going to store the data in our Domino application - basically - under a XML-like architecture. NotesItems for Nodes, etc. Then, we'll use our "skinnable" configuration documents which are simply - which if you haven't seen where we were going with this at this point - XSLT libraries, to transform our XML data at runtime into whichever content is required.

Before anyone says this is "overkill" - we know it is... if you follow the standard Domino Web Development architectures. What we're looking to achieve is something that may at this time be unique in the development community from a functional architecture standpoint, but something that we think will completely revolutionize Domino Web Development. No longer will we be resigned to "Domino doesn't do that" - you'll have complete control over the rendered content, allowing you to integrate ancillary technologies with ease.

At least... that's the plan...

As for the Vicondin reference... I'm about to head off to the doctors (again) as the Vicodin that I was on while recording Episode 2 ain't quite helping my back. MonkeyButter? You'll just have to listen...

Get it via:

• Subscribe to YellowCast (FeedBurner)
• Subscribe to YellowCast (Zune)
• Subscribe to YellowCast (iTunes)

Runtime for this episode is 1:06:41 - which we think is still long but we're getting closer. Feedback, comments, and suggestions always welcome!

UI development should really be specific to the type and functional requirements of the given application. Alternately, "branding" is a big requirement for most company applications.

(that last part always drove me nuts - "You must have the company logo in the top left of the screen...", as if people would forget where they worked whilst in my applications?!)

But back on topic...

So what exactly are we all looking for out there? What do our users need? What are they asking for? This isn't a "killer apps" question per se, but rather a question as to what Lotus Notes client applications (or, maybe not something that you would even consider doing in the Lotus Notes client today). Let me know in the comments!

Off topic:

I've setup a Twitter account specific to YellowCast at http://www.twitter.com/YellowCast. You can sign-up to get information about upcoming episodes or posed-questions to the listening audience. So sign-up and watch that (and this) space!

We've got a few more ideas for segments for the 'cast, including "Fallen Comrades" - where we interview an unnamed Notes guy who's currently mid-migration to Microsoft Exchange and Sharepoint. Promises to be interesting to say the least! This segment was scheduled to be included in the first episode actually, but due to both our want of getting it out the door and our contact's schedule... well, expect to see that in an upcoming episode.

Feedback on both getting YellowCast and the content itself will greatly help us (since I've proven that I have NO idea what I'm doing in this arena).

So subscribe at http://feeds.feedburner.com/YellowCast and let us know what you think - both good and bad - and we'll keep the episodes coming!

Lastly, I want to say a public thanks to Bruce, Julian, and Chris Miller, as well as anyone else who runs a podcast - you don't appreciate the amount of work required to make a single episode until you have to do it yourself. I liken it to speaking at conferences. Thankfully, our community is an amazing one, and Bruce help my pull my head out of my arse several times in the post-production phase. As always, you guys rock!

So, once installed, I was greeted with a really slick v8-esc Connections Client icon:

Check out Chris's article to get the how-to on connecting with your BleedYellow credentials.

Once in, we see the Connections Client home page - giving us access to Profiles, Dogears, Communities*, Blogs*, and Activities*.

Profile Search is pretty slick, allowing us to use the Profiles as a Mobile Directory, with call-out capabilities - very cool!

Dogears - this can be useful for the maintenance of mobile device client-friendly links and resources.

The rest of the client - and this is what loses me - is simply links to the web implementations of Communities, Blogs, and Activities.

Yeah - Activities isn't handled in this local client - W.T.F?!

So, to sum up:

1. RIM doesn't know how to get me the app.
2. Thankfully, our community rocks!
3. It looks purty...
4. Profiles and Profile Search will give you a pseudo-mobile directory on your device - pretty slick.
5. Dogears... ok, I can see where this might be useful.
6. Communities and Blogs - meh, grab a feed reader.
7. By far the biggest let-down: Activities are not maintained in the device.

That's my "First Impressions" having used this for the past few days, and while it's looks slick and I'll certainly use the Profiles - I'm looking forward to the next release in hopes that they'll include Activites.

]]> 05/19/2008 04:10:18 PM 1 http://www.dominoguru.com/pages/blackberry_Connections_Client_firstimpressions.html My Gear Chris Toohey http://www.dominoguru.com/pages/blackberry_Connections_Client_firstimpressions.html#c http://www.dominoguru.com/pages/blackberry_Connections_Client_firstimpressions.html As I use both BleedYellow.com, Lotus911's community implementation of IBM Lotus Connections, and a Blackberry 8820, you can imagine my joy when I found out that there was a Connections client from RIM! I immediately stopped what I was doing and went to work trying to get some Connections goodness on my preferred mobile device.

Having Desktop Manager, I thought that I'd download the installer and go from there. Pretty reasonable right? Well, apparently I assume a lot in life. With my devices.xml fully-updated, post registration on RIMs site, and installer package downloaded, I set forth to install the client on my 8820 - only to have Desktop Manager tell me it couldn't find any new applications for my devce:



Unphased by this setback, I moved onward...

I grabbed my device and starting looking to Blackberry for an OTA (Over The Air) installation that would remove any issues with my apparently wonky Desktop Manager.

Now, a little sidebar here - RIM creates these devices. They know what they can do and what they cannot do. More importantly, they know exactly what my device is (they friggin made it). So...

I find what I assume (there I go again) is the OTA installation, which requires that I yet-again register. The only problem, the RIM registration form runs script that doesn't work on even the latest devices. So, unable to proceed with the registration, I turn away defeated.

The good news? We have an amazing community! Chris Whisonant replied to this post telling me to check out his blog, where he hosts an OTA installation. Sweet! About 10 minutes later I was using the RIM Blackberry Connections Client to access the BleedYellow Connections environment.

RIM's Blackberry Connections Client - First Impressions - Part 2

]]> 05/19/2008 02:49:48 PM 0 http://www.dominoguru.com/pages/05192008120729.html Domino Development Chris Toohey http://www.dominoguru.com/pages/05192008120729.html#c http://www.dominoguru.com/pages/05192008120729.html After many conversations with people like Nathan, Declan, and my soon-to-be-mentioned co-author on this project (which will be open source and available to the community - it's all about the show!) - I realized that I was taking the wrong approach with thinking that Web Services could do what I needed it to do. What I need to do, for the content management system that I have in mind, is facilitate the ATOM Publishing Protocol (or APP) via REST - that's full support of the POST, GET, PUT, and DELETE methods.

This of course, we know that the Domino HTTP Server won't allow - and now I know that this includes no matter what you say in the Internet Site Document.

I tested this by creating a simple HTML file, consisting of 4 Form objects - each with the POST, GET, PUT, and DELETE methods respectively - that used an Agent Design Element as their posting agent. The Agent Design Element, called "rest_test" for my examples, would simply run a session and return the submission method and some other information via plain text Printing.

The result - well, POST worked fine. GET worked fine. PUT and DELETE were translated to GET method calls. Now, the translation wouldn't bother me so much... but it's seamless. Too seamless. I don't know that the original request was via PUT/DELETE. If you consider what this means...

PUT and DELETE are methods that are designed to modify their target object - update and removal respectively. Such requests are returned as GET - which is designed to fetch an object. Sure, data can be passed along to that object (to Domino developers, think ?EditDocument, ?OpenAgent, QueryString parameters, et al). But that ain't gonna work for what I'm looking to do.

So, after many discussions with my co-author, I think we've got a plan. It's a solid plan. It's a righteous plan. And it's something that will invariably allow extended functionality far beyond the scope of "yet another Domino Blogging template". We're going to a full-on, true REST-compliant content management engine.

More details to follow...

]]> 05/19/2008 12:07:29 AM 1 http://www.dominoguru.com/pages/05152008123805.html Domino Web Development Chris Toohey http://www.dominoguru.com/pages/05152008123805.html#c http://www.dominoguru.com/pages/05152008123805.html I'm going to make an assumption here: the majority of Notes Shops have not upgraded to 8.0.1 yet, and when 8.5 rolls out, they won't be upgrading to that immediately either.

I say that, because I know several companies who are planning to upgrade... but that plan has yet to be executed. So I'm going to assume that the 2 or 3 companies that I'm referring to aren't the only ones out there in the same situation.

I bring this up, because it was suggested by someone that I honestly respect (although I would never let him know that) that this new blogging template should utilize XPages for what I'm looking to do for the content management and delivery architecture.

Now, while I'll agree that XPages rock - I really want the majority of the Notes community to be able to adopt this solution. On the other hand, I want to be able to showcase something that's currently available to the majority of us but that might not be utilized.

So I'm thinking about doing this template all Web Services. Is that something that you use today? I know I don't. And I think that this is the perfect place for it.

So I plan on implementing the Blogger API into this template and adhering to it for all CMS-like functionality - all via Web Services. While I'm not ready at this point to get into all of the reasons why, I really plan on utilizing Web Services (which I'm going to make another assumption and say that we're not all using them in our day-to-day development) to do this as it will showcase an excellent built-in facility that can be found in more than the latest releases of the product, as well as outside of Domino Development.

So, that's the tentative plan - thoughts?

]]> 05/15/2008 12:38:05 PM 4 http://www.dominoguru.com/pages/05142008113934.html Site News Chris Toohey http://www.dominoguru.com/pages/05142008113934.html#c http://www.dominoguru.com/pages/05142008113934.html 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.
]]> 05/14/2008 11:39:34 AM 7 http://www.dominoguru.com/pages/05132008104147.html Challenge Chris Toohey http://www.dominoguru.com/pages/05132008104147.html#c http://www.dominoguru.com/pages/05132008104147.html If the surge in both development and adoption of solutions like TwitNotes and the pick-your-poision Instant Messaging clients (GAIM/Pidgin, Trillian, etc.) have taught us anything, it's that people prefer to use their own or preferred entry point into community and collaborative solutions. But what's this mean for the Domino application development community? Well, it tells me that I really need to consider architecting my applications to facilitate BYOUI - or Bring Your Own UI. Now, for corporate applications, you may think that this doesn't apply... but I wholeheartedly disagree! I think that if you really look at it, you'll see just how truly limited the majority of our applications can appear.

Let's take Twitter.com for example. If you were limited to only the website itself to follow and update your and other tweets, how many people do you think would adopt such a thing? Now image if you could only have the reading capabilities, but you needed to log into the website in order to interact - slightly better, but I'll still pass thanks.

With the architecture initially designed to allow ANY chosen client to interact with near-full fidelity, they've given me no choice but to use their service and say thank you!

Now let's hop back into the corporate setting, and say that you have... a corporate travel requests solution. Now, that Lotus Notes client application has all of these do-dads and amazing things that get a person from their cubicle and onto that plane to parts-unknown, but what happens when they want to access that solution via the web? Simple right? We modify the current Design Elements (or the smarter of us create new client-specific Design Elements) and mirror the Lotus Notes client. Now you're cooking with gas!

And what about when the users demand access via their Blackberry? Kinda simple, right? More modifications and more design elements, ahoy!

What about implementation into Portal? What if you needed external travel vendors and agents to access this solution, but only for a subset of functionality? All things you're bound to run into to be honest...

Now imagine that they want a new button, a new function, a new feature - kiss your next month good-bye!

By architecting a solution to maintain it's content both separate from UI and Client Type, we can do away with a lot of that headache. Such a content management engine that is made available to the BYOUI crowd would require a Web Services (or like) mechanism to provide access to the data and functionality.

All this is fine and good, I'm certain that all of you agree... until you understand what that means for Lotus Notes Client Type applications that adopt this architecture. See, moving to a Web Services-like engine for data access goes against everything that IS Lotus Notes Development.

As Notes Developers, we modify "documents", not data. Data is stored in those documents, sure - but we're ultimately modifying an object that contains data.

And that was OK when all anyone ever wanted to do was modify "documents" in a Lotus Notes Client... but today, the demands are different. It's total BYOUI for the employee at home, why can't they work that way in the office?! We can adopt a different development methodology and deliver the same choices from Client Type to Subset of Functionality.... but it's gonna require a change to the way the majority of us think.

I'm babbling here a bit, but with good reason - I think I'm right here, or at least I'm onto something...

]]> 05/13/2008 10:41:47 AM 3 http://www.dominoguru.com/pages/05082008091543.html Community Chris Toohey http://www.dominoguru.com/pages/05082008091543.html#c http://www.dominoguru.com/pages/05082008091543.html As I'm working on a community project (more on that once we get past the initial stages and flesh out some more details, etc.) with an individual that is outside of my organization, I needed a simple solution that would allow me to create and maintain a Project/Task/Sub-Task to do list that we could both work from. Enter bleedyellow.com's Connections Activities.

Now, if I'm any indication of Joe Notes-Guy, I hear of all of these amazing capabilities that are becoming available to use "Notes shops"... but I don't get the chance to really flesh them out. This is one of the reasons that I both jump at chances where I can utilize these new solutions or functionality within established solutions, and why I try to share them with those of you that find yourself in this same situation: life interrupts technology playtime.



It's with that in mind that I bring up Activities, which is absolutely cool. With my 8.0.1 Lotus Notes client, I can turn on the Sidebar Activities application and it's really an afterthought of functionality - it's right there. Makes you wonder if the integrated To Do List would get used today if it was always-on at the UI layer, huh?!



As you can see with these screen caps, I've got the projects and their tasks at my fingertips. With them right there, I can imagine that collaboration with project teams that reside outside of the physical location (or, for this community project, both outside of the location and into a global community!) is going to be MUCH easier - kinda like Tweeting is MUCH easier with the Lotus Notes client Sidebar application TwitNotes.

As for this project that I'm hinting to... unlike Zephyr and Yellowcake (which I'm positioning as low cost community solutions), the goal of this project is to provide not only 2 open source community-accessible solutions, but also do it utilizing ancillary technologies or spanking-new capabilities within Lotus technologies that us Joe Notes-Guys and Gals just don't get that much of a chance to play with - and via a medium which will lend to hectic schedules.

]]> 05/08/2008 09:15:43 PM 0 http://www.dominoguru.com/pages/04142008094134.html Site News Chris Toohey http://www.dominoguru.com/pages/04142008094134.html#c http://www.dominoguru.com/pages/04142008094134.html I've been using Twitnotes (currently release 1.0.3) for the past week or more, and a funny thing happened - I kept out of the blogosphere and pretty much out of my Inbox that entire time. Mind you, I really wasn't focused on Twittering all that much, but the Lotus Notes client add-on was in-my-face enough to keep me connected. In fact, my only contact with the outside world last week was through Twitter and the BleedYellow.com and Lotus Greenhouse Sametime environments. Project work (including something with IBM... but I have no idea how much I can get into that stuff here...) has been keeping me very busy at the moment. If you sent an email in the past few days, rest assure that I'm working through the list to get back to you!

At the very least, this might be an interesting study in just how effective a Notes side-bar application can be - despite my schedule I was still able to keep up to speed on the basic ongoings of the members of the Lotus Community (at least those who currently twitter anyways...).

But enough of that, onto the goodies:

Since I was so out-of-touch, I thought I'd make it up to those of you who kindly read my babble. Thus, in case you missed it, I published a new Notes Client Wizard Components application in the Examples & Downloads section of this site. RSS feed readers of this site would have gotten the update, but those of you who navigate to this site may have missed it. It's a few Design Elements that can be used (and modified - it's very vanilla) to create a content creation/maintenance wizard in your Lotus Notes client applications. I may do a formal article on the implementation of such a technique... when I get the time.

Those same website visitors (those who actually still use a web browser client to access this site) may also notice a change in the layout of the content in the right-hand column; I've added a "Contact Information" section as well as my 5 latest tweets. This pushes the "Publications" and "Examples and Downloads" sections down a bit, which I'm not exactly sold on as of yet. Another idea I had of displaying the 5 latest twitters was to create a 2-column layout where the current BleedYellow.com Dogears are today (under the latest Weblog entry on the index.html page), allowing me to display both said Dogears and the 5 latest tweets. The issue with this approach, you lose them once you navigate off of the main page. Mind you, I could have a dedicated webpage to both the Dogears and the Twitter updates... I dunno - feedback appreciated at any rate.

This week, I'll be working on Yellowcake, Zephyr, some other stuff, and hopefully getting a few things completed before the weekend. Here's to hoping anyways... ;-)

]]> 04/14/2008 09:41:34 AM 0 http://www.dominoguru.com/pages/wizardcomponents.html Lotus Notes Chris Toohey http://www.dominoguru.com/pages/wizardcomponents.html#c http://www.dominoguru.com/pages/wizardcomponents.html I find myself using wizards to create or modify documents in my day-to-day Lotus Notes applications - their utilization allows me to drive the user through the applied business logic while providing them with a simple user interface. I think it's both great UI design practice as well as an eye-opener for us Lotus Notes client developers who think that the only way to create and modify the NotesDocument is via it's form NotesItem-designated Form Design Element.

But enough of that, let's get to the goods:



Open this database in the Domino Designer client and we'll see the (app/wizard/wizarddocgen)|wizarddocgen Form Design Element. And that's where the fun begins! ;-)

]]> 04/11/2008 11:08:52 AM 6 http://www.dominoguru.com/pages/04072008101011.html Community Chris Toohey http://www.dominoguru.com/pages/04072008101011.html#c http://www.dominoguru.com/pages/04072008101011.html And feedback is appreciated! http://www.ibm.com/developerworks/wikis/display/dominoappdev/Home

This pre-population of what could become the definitive online resource for Domino Web Development is just the beginning - it's our solution, and up to us (the Lotus Online Community - and that includes IBM in my mind) to keep this a living, breathing, and ever-expanding resource.

]]> 04/07/2008 10:10:11 AM 1