Generating HTML inside documents - no 32k limit

Sometimes you might want to have an agent generate HTML for menus, reports, etc., and find it impossible to recreate this with a view.

This can be on webqueryopen, or you can have a document container for the HTML (to save strain on the server every time a document is opened), and use dblookup/computed text to get the HTML. For menus that show on every page, I think dblookups/container-documents are the best solution. For HTML-reports that are per page, use a Richt-text field..

With a text-field, you can have max 32k data per field, or 64k data if it is a multivalue-field (someone correct me if I'm wrong). With multi-level menus and big tables, you can quickly reach the limit of the field. What I used to do, was to put the HTML in a Rich-text field, and using an iframe or Ajax to get the data.

A simpler solution is to use multiple fields to contain the data. If the data exceeds 32k, simply continue pumping out data to another field.


Pseudocode

If Len(strHTML > 30000) Then
 doc.replaceItemValue( "field"+Cstr(counter) ), strHTML )
 strHTML = ""
 counter = counter + 1
End If

If you use a WQO-agent, have multiple computed for display fields, and make sure they're pass through html. If you don't want to want to generate the HTML every time, you can stamp the document with a date, use computed when composed, or editable fields, and only generate the HTML if something has changed/a day has passed/etc.

If you use a container document, make multiple computed texts with one dblookup each, as there is 32k (?) max length of text a computed text can represent.

Here's a demo-db: link

Open the bigfield-form on the web to see the generated table (WQO-agent is "generatetable").

Screenshot of the form (i generate 2000 rows on WQO):

Using embedded view in $$ViewTemplate to control count

This is a simple one, but not sure how many are aware of it. This will work for $$ViewTemplate for someView, and $$ViewTemplateDefault.

In a viewtemplate-form, you can use either a field named $$ViewBody or an embedded view to "hold" the view content/body of the view.

If you use $$ViewBody, you have to use url-parameters to override the default count of 30 entries.

If you use an embedded view in a template, you can control if the view-header is visible, border around the view, the default count (up to the limit set on the server, normally 1000 entries), the default target for ( notes-generated ) links in the view ( generates target-attribute on the links ). It doesn't look like you can disable the action-bar of the view though.

The simplest way to add embedded view to the template, create embedded view -> Choose a View based on a formula -> "" (<-- just use an empty string for the view formula, to avoid confusion in the future).

Demo-db: link

Run the "Make2000Documents" agent to ... generate 2000 documents. Test out different settings on the embedded view in $$ViewTemplateDefault, and open the subject-view to the the effect.

( There are probably a lot of bad naming practices visible in the demo-db. This is because I just started to test out some stuff, and then I decided to post the "stuff" here. ).

A couple of screenshots:


Default 5


Default 500

Simplifying maintenance of multiple similar fields

I bet most developers have made forms with several fields that are identical apart from their names. This method aims to simplify some of the maintenance on such forms, for Notes/Domino developers.

First, create a "computed for display" text-field.
This will be the datasource/contain some javascript/css/style (I know.. mixing data, behaviour and design, all bad stuff, but this is just an example).

Default value:

choices:="Norway|no;Sweden|se;Denmark|dk;United Kingdom|uk";
defaultvalue:="se";
htmlattrs:="onclick=\"alert(this.value)\" style=\"color:red\" class=\"country\"";

choices:defaultvalue:htmlattrs;

choices could also be a dblookup/dbcolumn. Remember to implode it, to allow for a fixed number of settings. Example: @Implode(@DbColumn("";"";"view";2);";").

If you have multiple similar non-multivalue fields, you'd probably just need html attributes, and maybe default value. Seeing as multi-value fields often have more settings, I'll focus on these.

Field properties -> Choices ("Use formula for choices"): @Explode(srcCountries[1];";")

Default value: srcCountries[2]

HTML Attributes: srcCountries[3]


Screenshots:

In the designer

In the client (border-style=none set manually before copy/paste)

On the web

Onlick (from the htmlattrs in the computed for display field)

REMEMBER! Describe the cfd-field containing the settings, so that you understand it the next time you're working on the form..

Formula-console in Notes

I really like this one, although it's a really simple one (maybe that's one of the reasons I like it so much).

Call it my Mac Gyver tip of the week (in a french blog, the tip to check the online status of the server with ecblank.gif/onerror-event was called something like that).

I've sometimes got really fed up developing formulas for computed fields, view columns, transforming dblookups, you name it. Just the other day, I thought this one up.

Make a form with an editable input field. Make a hidden SaveOptions-field (computed for display, default value="0").

The editable field is where you type formula-code. The nice thing about notes-fields is that they are multi-line, so you can write quite complicated formulas.

Below the text, write Result: or something like that. Then add a computed text with this formula:

test:=@Eval(inpEval);
@If(@IsError(test);@Text(test);test);


F9 (refresh) to execute the formula.. TaDa! You have your own formula-console.. :)

I have added a toolbar-button in the designer and client, so that I have instant access to the "console".
@Command([Compose];"server": "databaseWithTheForm";"nameOfFormulaConsoleForm")

A little update: If you use a button to @Eval the text-field, you can also execute some UI-formulas, that you can't execute from a computed text.

Using html and computed for display-fields for temporary values


Date: <input name="dateChanged" type="text" /><br />
Changed by: <input name="changedBy" type="text"><br />
Description of change:<br />
<textarea name="description" rows="5" cols="40"></textarea>


Hidden fields on the form:

<!--
Computed for display - default value/name=name of html-field
-->



<!-- Computed -->

Example code for the historyChange:

change:=dateChanged+", "+changedBy+": "+description;
@If(change="";
historyChange;
historyChange:change
);


This code concatenates the field-values to a string, and adds the string as a text-list item in the historyChange-field.

In the form that I use this method, I have a date-picker on the date-field ( and the field is readonly ), and the value is a computed text, @Text(@Today).

Other uses is for instance a checkbox that controls what happens to a document when it's saved, but has no other real purpose. The values in this example can be accessed by computed fields, webquerysave agents, etc.

Remember to put computed fields below the computed for display fields.