Saturday, November 3, 2007

Templating using a NotesForm

Coding templates in an agent leads to very verbose agents/a maintenance nightmare (in my opinion). Coding them in a NotesDocument makes it hard to use them in a Design-template context.

This technique has little verbosity beyond the actual code to generate HTML, and works great in a Design Template-context. It supports modularity, as each field is a potential module. Since the templates are forms, the dynamic "modules" also work in stored documents.

You can combine Java (through LS2J), formula (through Evaluate) and LS , just like you can when you're using agents for templating web-pages. If you're a Java-guy, then you probably would need a little more code (testing field names with Regular Expression) to achieve the same.

Combine this technique with @UrlQueryString in Form Formula if you want the ability to present data in several content-types.

The technique relies on Execute, a WQO-agent and field-names following a pattern. I chose Execute because it's faster than making a testing-routine for patterns. If you're planning on putting this technique to use in real applications, I suggest you use Regular Expressions, Instr, etc. to look for valid field-names, as Execute is horrible to debug.

The demo

I have one pattern that I look for in a field-name, "wqo_actonfield_". The third token (separator = "_") is the method to be executed. The rest of the tokens are ignored to allow several fields executing the same function.

You could also have the rest of the tokens being parameters for the method being executed.

For instance field named "wqo_search_google_dontpanic" -> run a function that inserts HTML with search-results into the field.

>> Demo Application.


WQO-agent for demo:

Form, one demoBody-field:

Result, web

Form, six demoBody-fields:

Result, web (click for full size)

As always, comments are appreciated :)


Veer said...

I didn't quite follow what you were trying to accomplish.

I downloaded the demo database, but it has got local encryption enabled. Can you check that out?

Tommy Valand said...

I'm not sure what you mean by local encryption..?

Default access is Manager, so everyone who downloads it should have full access to do whatever with it.


A design-element is itself a tool for templating, but it has its limitations. The limitation I've found most irritationg lately is that you can't put LS code in computed texts/fields.

In my PHP-like templating-experiment, I used a string (stored in a document) with keywords that an agent replaced with the results of Evaluate, a function-call, etc.

Here I use a form instead of a RT-field in a document, and instead of keywords, I use computed for display/computed RT fields with names following a pattern.

I haven't tried out this technique in any real applications yet, so I can't say if this is a useful or a useless experiment :)

Veer said...

Stan Rogers explains about how the encryption could have happened. Please look at this thread:

Tommy Valand said...

Thanks for the info..

To get rid of the encryption, I copied the db to a server, replicated it to local, unchecking encryption in options.

Let me know if it works now.

Bill said...

The local access protection is still enabled on this database. Looking forward to looking at the code. Thanks!

Tommy Valand said...

Did a new attempt.

Made the "old" db a design-template.

Made a new DB - refreshed the design from the old version.

Bill said...

It works now. Thanks, Tommy!