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?

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

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...

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.

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... ;-)

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! ;-)

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.

I've gone ahead and setup the Notes and Domino Developers chat room, where you'll find me today. So -- if for some reason you haven't done so already, get over to BleedYellow.com, sign-up, and get involved in this ever-expanding community!

So, many thanks Lotus 911 - you're giving us both a series of collaborative solutions that helps strengthen our global community and real-world adoptions of technologies that many of us have only seen in Powerpoints and product portfolios. You are and continue to be a true realization of the best in our community: people selflessly helping other people.

What makes Domino email go into the Inbox? There's no sniffer Agent Design Element waiting to do the legwork, so...

I (after getting out of the shower, of course) created a Folder Design Element named Inbound Email, and added "($Inbox)" as it's alias.

So, like $$ViewTemplates, $$NavigatorTemplates, $$SearchTemplates, $$Returnenter_type_here, the name/alias of ($Inbox) has a function based on the designation: a Folder Design Element with the name/alias of ($Inbox) will receive and store inbound email messages.

Looking to play around with the technology (while in the final days of the ITSO residency, I don't have the cycles to *write* any examples myself), I setup TwitNotes and suggest that you do the same (awesome work Mikkel). This of course had me creating my own Twitter account, so "add me" as a Twitee if you're so inclined.

Speaking of adding, I'm more than happy to announce that one of my long-time friends and fellow yellow bleeder has decided to get off his ass get inspired enough to start his own weblog: DominoDragon.com. Erskine Harris, said yellow bleeder, is a smart guy and a good developer (even if he occasionally listens to me for advice).

More updates later... maybe even via Twitter!

We evaluated your blog based on the following criteria: Frequency of Updates, Relevance of Content, Site Design, and Writing Style.
After carefully reviewing each of these criteria, your site was given its 8.0 score.

So first, a public thanks to whoever reviewed this site and gave it such a high score! I would have honestly liked to know what could be done to improve the score... and that statement warrants some explaination.

I'm a big believer in reviews - but I don't want the sunshine-and-happiness type of review, as while it's good to receive accolades for a job well done, I don't think a glowing review gives you anything you can work on; you don't get an unbiased overview of areas where you could improve.

That's what I'd like to know -- I don't want to know "why wasn't I a 10" because I want to be a 10-rated site, but I want to know "why wasn't I a 10" so I can work on any particular shortcomings and improve both myself and the site. Does that make any sense?

For those of you inclined, speak up and tell me where I suck can improve in the comments of this post.

The kids had a blast! Hell, this kid had a blast! My wife, who has still yet to see the movies... enjoyed her family's joy! ;-)

While I was disappointed that some of the displays were malfunctioning (due to lack of staff on-hand and the foot traffic I'm certain), I know the family had a great time while getting to learn about magnetic propulsion, robotics, and how today's science fiction is tomorrow's science fact.

So, you have this kichen-sink application suite consisting of 300 modules that don't quite address the original business need that started this whole process in the first place... but you've spent all that money already so you make it work.

For some people, that's "sucking it up" and dealing with the functionality gap. For others, it's modifying the codebase of the purchased solution. The problem with that... you can't (or can't easily) upgrade once you modify the codebase to include the functionality that you need to address the original business need.

And people win awards for this...

So what's a better way to do things? Now - please keep in mind that Clearframe has it's own CRM/SFA/ET AL solution... but I'm beginning to think that it's time to move onward to something better - something that allows for both real collaboration and something that meets the real business needs of the customer. What that is... I dunno. This post wasn't anything more than a brain-dump (sorry for those expecting a coming-soon commercial or something like that)... something that was (and has been) on my mind for quite some time now.

So is CRM dead? Has it evolved into something else? Does it have a need to evolve, but we're not quite there yet? Random thoughts on a Monday...

So I jump over to the BleedYellow Sametime community, and after a quick chat with Nathan and Whiso, Lotus911 quickly setup a remotely-accessible Domino 8.01 server for us!

Now, constant readers know that I have nothing but love for the crew at Lotus911 (something about "What do you get when you get the experts in the field together in the same room..."), but still... they never cease to amaze me with their commitment to the community and their eagerness to help fellow yellow-bleeders.

If you haven't already, go over to Bleedyellow.com and sign up - if for nothing other than to utilize the Sametime community. It's not just the gang at Lotus911 but also other A-list community members that are just an IM away (I'm looking right now, to name a few, at Balaban, Elgort, Blatnick, Lynch, Pettit, Novak, Castledine, McDonagh, Bulloch, Elsmore, Stephen King....?!).

I can remember a few weeks ago running into an issue with design elements and a mal-cascaded template architecture gone awry. Within 2 minutes I had my answer, and it was 2 minutes because Whiso, Mike Smelser, and Trip had to wait for me to explain the issue in a 4-way chat.

Yes, I'm a Bleedyellow.com fanboy... and there's no reason that you shouldn't be one as well! Now, if you'll excuse me, I've got a wiki to populate ;-)

Came across this in the Confluence Notation Guide - which begs the quesiton: which famous/infamous characters do you use for your examples?

We've also decided (but it's not "set it stone" as of yet - so things might change) to utilize the News section of the Wiki (which is basically a blog) to hash out discuss various methods, practices, and make sure that the agreed-upon "best practices" are truly best practices.

This part of the whole process is what excites me the most! You, the reader, will get to see the discussions behind what made it in (and what didn't) - giving you a "logic trail" and acts to immediately dismiss the "Why didn't they do this?"-type of questions. I don't think you'd get that with on-site residencies personally, no matter how great the meetings notes were - and thus this immediately (to me) becomes one of the greatest benefits of this particular residency. Great stuff indeed!

As for the content that's going into this Wiki... well, it's got the potential for being the resource for all Domino Web Development. Of course... I could be biased ;-)

Let's take a look at the @DBLookup Function in all it's glory:

@DbLookup( class : cache ; server : database ; view ; key ; fieldName ; keywords )

We'll go with the cookbook method:

Ingredients

• 1 Form Design Element
• 1 Navigator Design Element

Long list - I know.

So, we'll start by creating a blank Navigator design element named "dblookup". Now, create a Form design element called "$$NavigatorTemplate for dblookup", setting the Content Type to "text/plain", and adding the following fields:

• SaveOptions
• Set to "0", since I don't want this to ever generate content - just render it!
• Body
• Which will be a Computed Rich Text field - see Formula below...

The Body Formula:

@DbLookup( @URLQueryString("class") : @URLQueryString("cache") ; @URLQueryString("server") : @URLQueryString("database") ; @URLQueryString("view") ; @URLQueryString("key") ; @URLQueryString("fieldName") ; @URLQueryString("keywords") )

Disgusting isn't it?!

It's usage:

db.nsf/dblookup?open&cache=NoCache&view=someviewname&key=somekeyvalue&fieldName=returnfieldName&keywords=%5BFAILSILENT%5D

This, as you can see, will do a "NoCache" DBLookup in the current database against the someviewname View for somekeyvalue, returning the value from the NotesItem returnfieldName, and returning "" (blank) when the lookup fails.

The reason that I'm using Plain Text as the Content Type is to allow for usage with AJAX functions, and the Rich Text is used to allow bigger lookups. Need it to do something more, expand away!

"Okay, you lost me..."

When you architect your applications so that data is presented and maintained as data, and not implicitly linked to the UI - your UI becomes a variable. This is an AMAZING option for your Domino applications. And this is (typically) done by defining a API, or Application Programming Interface, for your Domino applications. Simply put - you define (and then build) all of the data processing and maintenance elements for your given application, and then build your application to utilize said definitions/elements.

Take a look at Google Maps API for example. You have all of this data at your fingertips, and having a defined API allows you - the very capable developer - to build whatever UI you wish to access said data. Even better, the defined API allows you to integrate the application with countless other technologies.

You can see examples of this across the blogosphere - developers putting their component application development chops to the test and coming up with some amazing results. So why not take our Domino application development to the next level and define APIs for data maintenance?

And going this is, if you didn't hear this word enough already in this post, simple... at least after you get the hang of it.

Remove the UI from the equation - pretend you had to do everything from the back-end - now how are you going to create/maintain the data in your application? The answer, you'll tend to find, is maintenance of data via the combination of defined configuration document(s) and a commonly-accessible engine that utilizes said document(s) to create, modify, and delete data in the Domino application. And how do you display data in from a Domino database without hard-coding markup in NotesItems? Introduce translation layers for your data, which - depending on the given client type - can conditionally render markup and different content types.

Over the next few days/weeks - in between customer projects, the Redbook residency (which starts next week, btw!), Yellowcake, Zephyr, and a few other things that I have on-the-plate - I'll try to come up with a few rip-and-play examples of what I'm getting at here. Until then, expand your minds and start getting away from Domino development practices that brought you storing markup in fields and hacking Domino RAD-generated architectures to get slightly prettier Web2.0 UIs (both of which, I've done myself countlessly in the past).

As I see it - I have two real options here:

1. I can release these applications as open source solutions/free ware.
2. I can charge a small fee for each application or create a subscription service.

Each one of these options has their merit, quite frankly. And in the spirit of being open about such a decision...

If I were to do both of these solutions - which I think absolutely rock (but I could be a little biased) - as well as any other solutions as open sourced free-ware, I can all-but-guarentee that it'll be a v1.0 release-and-done type of thing. It's not that I don't think there will be bugs to fix, enhancements to make, etc. but rather that I don't think I'll be able to logistically invest the time required to create documentation, field the occasional question, fix the occasional bug reported from someone, or to expand the solution further with a vN.n release(s). And I've done this in. the. past.

I want these two solutions - as well as a few others that I have in the pipeline - to reach their target audiences (both Administrators and Developers) - and be able to provide them with both support of the current "releases" as well as support via updates and code-fixes/enhancements.

So I'll pose this question: would you be interested in such a subscription service?

Here's what I've thought up so far: There will be two different subscription levels, individual or subscription.

• Individual
• $25/Year
• Access to individual product, and it's releases/updates.
• Access to the individual product discussion forum.
• Access to support via forum.
• Subscription
• $50/Year
• Access to all products, and their releases/updates.
• Access to all product discussion fora.
• Access to support via forum.

I think that these prices are reasonable really - allowing both individuals and corporate-backed developers and administrators the chance to get their hands on the given products. But I need your feedback on this (hence this blog). Am I being unreasonable in asking for financial reimbursement for such a time investment? Am I being clear on what's my intentions are here? Who knows... maybe I'm still in that morning haze?!

While on "autopilot" and this happens, I am always thinking that I missed my exit and went too far down that particular stretch of road (which I'll admit that I've done in the past). Today, however, was just a particular part of the highway that I must have never noticed... which always kind of worries me. I don't know - I just get thinking...

Stuff like this ever happen to you?

I was actually on an interview a few years ago for a rather big-name product development company, when they brought in their lead developer to ask me a few technical questions. One of the things he asked me, was whether I developed common design elements or used individual (per Client Type) elements. In case I lost you there, do I have one Form design element for the Lotus Notes client, Web Browser client, and Mobile Device client types. In horror, I said "No - that's insanity. The only way you could pull that off is with hide-whens or subforms or something just as resource-consuming..."

His repsonse, which added shock to my horror, was that "[doing that] was [his] biggest pet-peeve" and that the products that they developed all had common Client Type design elements. He wanted to cut down on the maintenance of all of these design elements by having single design elements per all Client Types.

While such a thing can work - I don't recommend it. In fact, I'll be a little more stern with my suggestion: Don't do it!

An application that is delivered via both Lotus Notes client and Web Browser client has major environment and usage considerations. Creating multi-client applications (especially when you factor in the Mobile Device client type) requires both an understanding of the application (what it does, and how it's being used) as well as an understanding how the to-be-supported Client Types are going to work.

I can hit my application with a WAP browser, but I can't use the advanced JavaScript that my Web 2.0-based UI uses. Do I take that same design element and play the hide-when game until I've got some "You came in that thing? You're braver than I thought!"-Monster Design Element that no one wants to touch for fear that it'll break everything, or do I hide that design element from Mobile device types and create a WAP-friendly equivelent?

So, to recap. Don't be an asshat Create seperate design elements for your various supported Client Types whenever possible - which should be all of the time.

I've gotten a lot of feedback - most of it offline, are people reluctant to comment?! - regarding the example notifications utility that I mentioned when discussing MMM yesterday - so much so in fact that it warrants me creating a new project here. And this is where Project: Zephyr is born!

Here's a diagram of the basic architecture of Zephyr, which will be a super-user-defined notifications utility for IBM Lotus Notes/Domino, that I quickly threw together:

Here, a copy of a document from a defined source Notes Application is placed in Zephyr. A scheduled Agent will run against all newly added documents, and check to see if an email template for the given source Application matches based on a defined criteria. If there's a match, the Agent will run a mail-merge of the source document and the designated email template - the result creating an email in the server's mail.box!

Simple stuff, I know.

I'm still hammering out the logistics here, but I already have a few production copies of this same utility floating around a few customer locations so I both know that it's a solid and useful solution. Left out of the diagram is the logging and retention-logic of the source documents.

One of the outstanding questions is, however, "How do I distribute it?"...

The Mail-Merge Method, or MMM, is something that can pretty much be applied to anything - from notifications, UI document rendering, dynamic content, and countless other uses. In fact, I'm actively using this method in Project: Yellowcake to generate dynamic content markup on-the-fly... but that's a story for another post!

MMM basically consists of the following:

Author's Note: My first thought was to just now write "Step 1:", which was immediately followed by "Cut a hole in the box..." ;-)

1. Create unique-to-the-engine keywords.
2. Create a delimiter string that won't normally be used in your content, which you'll use as a wrapper for your keywords. For example, I tend to use <<keyword>>, but you may want to get more unique than that: %^&keyword%^&.
3. Create a simple merge-point for your expected content.

If I lost you on that last step, that's ok -- it requires a much deeper explanation than a single bullet-point...

To illustrate how effective MMM can be (as well as help define the method), let's say that you want to create notification email-functionality in your given workflow-based application. Most people would either write an email on-the-fly via @Formula (<shudder>) or get really tricky and write a simple-and-static email generating Lotuscript-based Agent Design Element called "notifications". "notifications" runs either on-event or on-schedule, but basically grabs a document and generates an email to a given recipient with a doclink and some information on the given document.

Simple right? Add a field. Now change the font-weight for a given item in the body. Now put a red-colored, 8pt font-size disclaimer footer at the bottom of the email that says "This is an automated response, please do not response and think the sender actually cares...".

You'll spend more time playing around with the formatting of the email message than you will with the workflow of the application itself. Trust me - I used to do that.

And before you ask "Why should I care what the email looks like?", consider this: it's arguably part of your job to show just how flexible and helping the given technology investment can be - and giving someone pretty email notifications can be a very simple and effective way of showcasing the capabilities of the technology... but I digress.

So you've got this notification, but you have to maintain an arm-length codestream for formatting, etc.

Now imagine this instead:

I take a simple Form Design Element, which I've called template_email, to create various "email templates" which my notifications Agent simply grabs en-masse and replaces <<keyword>> with the keyword's correlating NotesItem in the given document.

This allows me to create a simple Super User-Defined Notifications Engine in my various applications... which not only provides the application administrator the ability to create and maintain their own notifications, but it also keeps me out of the Domino Designer client playing around with RTItem formatting. The user community benefits from my laziness!

And this is only an example of MMM. In Project: Yellowcake, I'm using the MMM approach to get some pretty amazing functionality... but like I said, that's for a later post.

I'll work on getting both more examples of this method as well as my Notifications Engine out ASAP - provided there's an interest in such a utility. ;-)

IBM's International Technical Support Organization (ITSO) in Rochester is pleased to formally accept your nomination of Chris Toohey as a remote resident in Residency LO-8001-R01: Best Practices for Building Web Applications for Domino 8.

There goes the neighborhood... ;-)

A 5%er, in this context, is my way of saying that I think only 5% (or less) of the Development Community-at-large would ever use - let alone think to use, given requested functionality. Most of this stuff might not even warrant a say over at IdeaJam... as it's micro-specific to a certain type/style of development and application architecture...

Anyway...

I'm currently working on a CMS (Content Management System) that will allow a given user to build a simple-to-mildly-complex website that's both maintained and rendered in Domino. One of the "functions" within the CMS is going to be to allow a given user the ability to create their own JavaScript, CSS, HTML (obviously), and other content to be used throughout the CMS-driven website. Simple stuff right?

Long story short (as I need to get back to it...), I have to define individual design elements if I want to control the content type of a given document! There's no - and if there is, please let me know - way of controlling the content type of a document based on the document context! For example, if there was a field called ContentType, you could set said field to text/plain and have this field control the broadcasted content type when the document is viewed.

A work-around I have however - although it's not as good as being able to control the content type via document context - requires an individual Form design element for each type of Content Type you will to render. When you call the given "document", you'll really be calling your Content Type Form design element, creating a "response" document (that you'll never really save), and inheriting the document context into said "response" document:

db.nsf/css?openform&ParentUNID=6b87e303374b19148525639a00506656

It ain't pretty, and requires additional Form design elements in order to render such... but one could argue that this lends more to separating data-from-design architectures, which I'm a huge proponent of (life's ironic ain't it!).

1. Is there any reason that you can think of that you would not want to create a Full-Text Index for a database if it meant said database could be fully web-enabled with no customizations to it's design?
2. There's Domino Applications and Domino Databases...
3. ... that being said, everything that we do is basically moving text around. Whether that text is markup of a sort that builds the rendering engine for your applications or the actual data stored within!
4. The best thing that you can do is share your idea with like-minded people. Don't be intimidated, worried, or afraid your IP will walk...
5. If you have to worry about said person walking with something you're sharing with them... why do you even speak with them?
6. How many of you are into Video Podcasts? Do you prefer Audio-only? Could care less either way?
7. 16 Processor Ticks and <1 second renderings are great... but if you're new-hotness shows an Agent Done when something goes wrong, you're not finished!

That last one should tell you - I'm not done with Yellowcake. I'm currently working on some things, including accounting for PUT and DELETE HTTP methods (calling Yellowcake a REST API without such support is apparently a misnomer otherwise). I'm already giving you the ability to create, modify, and delete target Domino Database documents/data via GET and POST... but I want to make this as powerful and capable a solution as I can!

I'm getting both amazing results from Project: Yellowcake, as well as seeing some of the solution's limitations. A lot of these are easily addressed (the architecture of the solution allows for that - THANKFULLY), but two tweaks here and four tweaks there... well, my in-my-head release date might just be blown as a result.

Here's a simple example:

Let's say you have an Application Profile defined for your Domino Directory. I give you the option to query this Domino Directory via a simple GET/POST HTTP request (so you can grow your own forms and use them to query the NAB) and return a result set rendered via the given Query Template configuration to whichever content type and formatting you wish.

This is all great - absolutely wonderful stuff - but what if you want to pull up a given document?

Well, right now, I have two types of "actions" if you will - Query and Save, each of which are controlled by their own mechanism and applied logic. For v1.0, I thought that this was good enough. Well, you can pretty much tell what I think now... but I digress.

So, my plan for returning a given document was this: use the QueryTemplate to return a count=1 document collection against the target database. The query would have the document's unqiue ID (@Text(@DocumentUniqueID)) and use that information to get the target document, spin it through the Query Template's rendering (a specific one created to display the given document) and give you the read-only document (and theoretically an editing-friendly format as well - just a different Query Template result rendering...). Simple right?

Well, unless you know of a way to (without modifying the target database or target document) do a db.ftsearch and basically get @Text(@DocumentUniqueID) = "blah"... I'm going to have to account for this by exanding the current engine.

This, outside of crashing servers and just not having things work, is why we test! Due to this limitation (again, if you know how to do this - please share!!) in the FTSearch engine, I need to get back to writing...

Simply put, the user client accesses the Domino application - which has been designed/modified to account for the given user client type - with direct reads/writes to said Domino application. The application design requires that security, functional UI elements, and such be built directly into the given Domino application. This architecture is nothing new to Domino Developers, but can often cause issues when a given developer does not recognize the need for separation between data and functional application UI.

The more advanced application architecture for a user client interacting with a Domino application is this:

Basically, the user interacts with a conduit or API that allows an interaction point between applications. Now, this conduit/API is typically pretty hard coded - and you see that with the web service APIs that are out there today. Check out the Google Maps API, there are statically-defined API that allow for some pretty amazing extended functionality. The problem with this approach - you are often afraid to touch anything. The conduit app is fairly hard-wired, designed for this singular need (the given API). This can often restrict both development and administration efforts, as not only is it a chore to expand the scope of functionality in your Domino applications (and forget it if you need to bring in a fresh developer who is not familiar with the given conduit design...), but the admins can't easily move databases to other servers or directories without full-well knowing that it will break something, somewhere, at sometime!

Now what is Project: Yellowcake? Project: Yellowcake is, simply put, a configurable REST API for Domino applications.

I came up with this approach and thought that I had invented the wheel - only to have someone tell me that it was a REST API - or a Representational State Transfer API. So a public thanks to Nathan for that one!

So here are some specifics about just what Project: Yellowcake is, for those of you who are still reading this far into the post...

You - the Developer/Admin, can define an Application Profile. The Application Profile will contain information about the target Domino application - both server and database, as well as allow you to define a specific dbkey - which is to be used as a key for any interaction with this particular application. One of the best parts? Admins can move the database to another directory (or another server for that matter), and all you will need to do is update the Application Profile with the target Domino applications new location! (see that, it's ADMIN-friendly!!)

You can then create either a Query Template or a Save Template for your given Application Profile. While the names should prove the following description unnecessary...

Query Template:
You will define both Content Type (by default, you can return HTML, Plain Text, XML, CSS), the result set formatting, and a given appkey. When the given appkey is invoked - typically via a GET/POST of sorts, the Query Template Author-defined API arguments are passed to the REST API, returning a NotesDocumentCollection from the target database. The Query Template then will iterate through the collection, and merge your result set on-the-fly (think of a Mail Merge), and build your resultant markup.

Save Template:
You will define one of the only static API parameters - docid - and invoke the Save Template via (typically) the result of a Form element's processing agent. The Save Template will then iterate through a series of WebQuerySave-like events that will be evaluated against the target document (defined via a combination of the dbkey and the docid parameter). Currently, the trigger options are running in-line Formula, running an Agent in the target database, or redirecting to a specific URL.

I'll post a few more entries defining the real-world usages of Project: Yellowcake in the upcoming days... while I search for a private alpha team for testing this thing out while I clean up some things...

If you're interested in being on the angel-round private alpha team, please contact me. Otherwise, check back here for more details in the upcoming days...

• Disney is opening an American Idol... ride of sorts. I wonder if they didn't get the idea from Lotusphere?!
• I'm looking for a video screen capture/podcasting solution... for the PC (a Mac is in my future, just not right this minute). As with anything, the free-er the better! Suggestions can be left here (preferred, as we can all share-the-love), or emailed!
• FCKeditor 2.5.1 - so many options, so touchy (the URL logic is enough to drive the most seasoned DHTML developer batty...), but so worth it! The CMS that I'm currently working on - and that's not Project: Yellowcake, which I'll be babbling about all this week - is really coming together as a result of FCKeditor implementation.
• I wonder if the guys at Microsoft, specifically the SharePoint team, are behind stuff. like. this.
• On a personal note (and I'll spare you any pictures)... the toenail on my recently broken toe finally fell off. If you've never had this happen, it's a little unsettling. If you've never had this happen but have seen The Fly... it's downright horrifying!!
• This site is apparently hot lately, or so says PlanetLotus.org (which rocks BTW!!). You guys like the updates lately?!?
• And lastly - for those of you who like Mashups... Tunes at Good Blimey!!

I'm so ashamed... especially since I went directly from this blog quiz to my blog to update my blog about my blog addiction. Blog. :-P