Showtime
My Blackberry Enterprise Server Push Utility for the Lotus Notes Client, allows you to create Jobs for individual Channel, Message, and Browser Content Pushes, as well as allows you to delete Pushed Channel Icons from defined recipient devices.
Contact Information
Blogger, podcaster, writer, and geek Chris Toohey covers topics from application development to the latest must-have-gadgets.
dominoGuru.com on Facebook
Latest Updates
Products & Applications
Time Tracker
The idea is simple. At the start of your day - upon completion of your first task - create an entry highlighting what you did and whether you feel it was an efficient or inefficient use of your time. Based on several requests, you can also select the priority, apply categories, or even align your time against a project.
For Lotus Notes Client v8.0 and above, you can use the Time Tracker Widget to make this process even easier!
Zephyr
My Configuration-based Rich Text Mail Merge and Emailing Utility, Zephyr allows you to create rich, data-driven emails to support automated workflow - all via Microsoft Word Mail Merge-like architecture. Dear <firstname> allows you to personalize each email message not only to the individual recipient, but also to the individual application workflow event!
xCopy
xCopy is a simple configurable xCopy client for the Lotus Notes client. By creating and defining xCopy Profiles, you can batch process your file backup or remote upload jobs. With the addition of the xCopy sidebar widget, you can easily kick-off these jobs, and modify both the xCopy Profiles and xCopy itself.
Community & Resources
Lotus Technical Information & Education Community
The Lotus Technical Information & Education community is comprised of IBM, business partner, and customer subject matter experts who use product wikis, published articles, white papers, community blogs and the latest in social media to build and share high quality technical content.
OpenNTF.org - Open Source Community for Lotus Notes Domino
OpenNTF is devoted to enabling groups of individuals all over the world to collaborate on IBM Lotus Notes/Domino applications and release them as open source.
developerWorks Lotus : Wikis
Share your deployment experiences and best practices in our wikis and help IBM to create scenarios for successful deployments. Contribute to the community by collaborating on shared content and leverage the shared knowledge from that community.
Domino as an XML data store and a servlet as a message broker? We'll see!
06/03/2008 04:00:33 PM by Chris Toohey
So, while chatting with Tim last night about just what we are going to do with Broker (for those of you who haven't been following YellowCast <shame!> - that's our public will-be-open source Domino CMS project that's currently in the works), we thought that we would split out the workload.
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:
- Complete separation of client UI and data.
- Treating the Domino database as an XML data store.
- 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...
|
Unless otherwise stated, this work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |
Chris, I swear... I can never understand what you're describing when you write something like this. :-)
Can you replace every instance of "utilize" with "use" and "communicate" with "talk?"
And I'm really confused by your description of your data store, because you say you'd have to write a web services consumer from scratch. You're talking about a data store -- don't you need a web services PUBLISHER? What would the data store be consuming? That doesn't make any sense to me.
@Nathan:
For the CMS, at least how I understand the industry-lingo, you'll need to build a web services consumer for web service-based clients that need to interact with our data store (again, Domino). So the message broker (our servlet) will consume the web service request(s), the broker will communicate directly to the data store (again Domino...) to create/modify/delete entries based on how you've defined (via the configuration documents - there's the skinning potential) what it's supposed to do with the given request.
Now, as far as the architecture of the data store, we're going to keep this as XML-ly as possible. As simple as possible. And those "configuration documents" are going to be the thing that does the "heavy lifting". Think Decepticon + YellowCake + Broker.
... not that that would clear up anything to anyone else... but I didn't use "utilize" once! :-P
As far as I understand your approach, Notes client applications aren't your focus (nor easily doable). It's about Web applications and for clients, which could been build "around Web services".
Thus lead me to my essential question:
Why do you want to use Domino as your back-end system?
You are building a data centric application. That's okay, but most applications I do are more or less process oriented, including some workflows and such. Therefore my next question is:
What's about the application's logic? Where should/could it been placed?
Web services are great for some applications. But all solutions about security and encryption are still needing some (or some more ;-) ) amount of work. My third question is:
How do you want to built in data and transport security (besides SSL)? Authentication? Data access control?
There are the Domino security features, but they rely on data stored in documents and accessed as documents. How you plan to translate this to your servlet/XSLT approach?
Don't get me false, I think, yours is an interesting approach, but I still don't believe, it will work well. Or you invest so much work to get it working, an existing Java, (G)Rails or such solution would be a more effective approach.
Thomas