Chris Toohey | Domino Guru

I've developed intranet/extranet/internet solutions for organizations (esp. my smaller clients) that wish to maintain their own environment without bringing a consultant in-house or farming the work out every time they wish to make the slightest modification. The majority of these people are technically-savvy enough to write the DHTML code themselves, but they don't know Domino, and want to start using their Domino solution for something more than an Apache alternate. (One customer in particular comes to mind, as they were putting all of their HTML into the Domino design as Image Resources, as they thought that this was how you did it in Domino.

It's with this in mind that I began using a Document-based approach to the management of the majority of these systems. In this post, I'll walk you through the utilization of such a method and hopefully leave you with a sense that while we've certainly come away with a working, implementable example... we've only touched the surface of what we can do as we now have control of the Content Type for our design elements!

Synopsis:

We will develop a document-based CSS and Javascript management solution that will yield W3C-compliant markup!

Ingredients:

( 1 ) Domino Server Notes.ini Modification
( 3 ) Form Design Elements
( 3 ) Views Design Elements

---

We'll start with the more ominous sounding: the Notes.ini Modification.

This lends to the W3C compliance more than anything: using ! in your URL-string instead of Domino's standard ?. To allow this, simply add the following to your Domino server's Notes.ini file: DominoXURLProcess=1

This will allow you to use the following URL syntax:
http://server/dir/database/view!openview&count=10

---

For our 3 Form Design Elements...

First, we will build a content management form, used strictly for building and managing the documents that will makeup our CSS and Javascript libraries.

A few guidelines for fields that you'll want to include in here (outside of anything your-applications-specific, of course) are as follows:

FIELD type : either css or javascript
FIELD name : used as either the design
FIELD content : contains CSS or Javascript content.
FIELD status : toggle @true|@false
FIELD position : number field values used for document sorting

FIELD vinclude : computed and designates which view to include this document in (see here for more details: here)
Formula: @If(status; ""; type = "css"; "main.css"; type = "javascript"; "main.js"; "")
FIELD vcontent : computed and contains the logical 'markup' for a given option based on it's Type and Content.
Formula:
n := @If(type = "css"; name + " {"; type = "javascript"; "function " + name + " {");
c := @If(type = "css"; content + @NewLine + "}"; type = "javascript"; content + @NewLine + "}");
n + c

The next two forms will serve a very simple purpose: $$ViewTemplates for our content views (which we'll get to) - one being for the Javascript and the other the CSS libraries.

FORM: $$ViewTemplate for main.css
Content Type: text/css
FORM: $$ViewTemplate for main.js
Content Type: text/javascript

I point out these content types, because aside from that, we're going to keep them relatively the same: an embedded view set to "Treat Contents as HTML" (or $$ViewBody, your preference), with no surrounding displayed text (unless you want anything static in either of your libraries, of course)!

---

Now, our ( 3 ) Views...

First, our content management view - broken-down however you'd like really - as the "admin" will be the only one seeing this view.

This method's application really relies on the delivery and maintenance of what the end user experiences, not the administration UI per se (outside of the content management - field validation, for example, isn't part of the scope of this post).

Our other two views, however, will provide the function of the maintenance. They also just so happen to have the same identical make-up:

View: main.css
Column 1: position | sorted ascending
Column 2: vContent
View Selection Formula: SELECT vInclude="" | @IsMember(@Subset(@ViewTitle;-1);vInclude)

View: main.js
Column 1: position | sorted ascending
Column 2: vContent
View Selection Formula: SELECT vInclude="" | @IsMember(@Subset(@ViewTitle;-1);vInclude)

---

Now, using this basic blueprint, you can build a CSS and Javascript Library mechanism into your Domino applications, thus utilizing Domino's allowance of controlling a Design Element's Content Type and Domino's native document management to deliver a solution that's atypical yet solid, simple, and something that keeps your tech-savvy customers happy: the lack of a dependency on a consulting engagement each time they wish to change the background-image of their page headers!

---

Add a New Comment

Name
Email (Not Published/Public)
Website Remember my Information!

Anti-Spam (Enter the text from the image to proceed)

(Full markup allowed in the comment field below; play nice!)

Comments

Live Comments Preview

 

---

The content of this site carries no warranty.
All design and content © dominoguru.com 2003-2008 unless otherwise noted.
( designed and developed by Chris Toohey unless otherwise noted )