A few quick tips today....

11/01/2005 12:40 PM by Chris Toohey

1) Web Views: utilize aliases for your $$ViewTemplates

Let's say you have 5 views in your application - and they all have the same surrounding html/elements/functions/etc. There's no need to have 5 separate $$ViewTemplate for X design elements - simply alias one of the $$ViewTemplates with the names of the others:

$$ViewTemplate for v1|$$ViewTemplate for v2|$$ViewTemplate for v3|$$ViewTemplate for v4|$$ViewTemplate for v5

Now, you can still control the templates with a single design element (easier on the developer, by far), and lock down the $$ViewTemplateDefault to ensure that someone won't stumble onto something that you don't want them to (in the event where they'll need access to those views for lookups etc. and access control just isn't an option!

---

2) Computed Subforms: Subform naming schemes can decrease computed subform logic!

Let's say (and a perfect example of this came up the other day while talking with a good friend), you have the following situation.

I have a field called htype, which value can be set to "rock", "paper" or "scissors". My current computed subform formula looks like this:

@If(htype = "rock"; "rocksubform"; htype = "paper"; "papersubform"; htype = "scissors"; "scissorssubform"; "")

The above, of course, would display the correlating subform for the selected value in htype. But there's an easier way...

Simply rename the subforms to the values:

rocksubform|rock
papersubform|paper
scissorssubform|scissors

And now, you're computed subform formula:

htype

This will now, without any additional calculation (since you're already looking up the value of the field AND a subform by name) display the correlating subform for the selected value. This trimming of formula on a global scale could greatly, in my opinion, increase performance across your applications!

---

3) Shared WebQueryOpen

This is a reiteration of an article that I published, but a good point nonetheless: let's say you have a formula-based WQO event on multiple forms; a hitcounter, for example.

You would typically do the following: create an agent called "hitcounter" with the function: FIELD counter := (counter + 1) In your form, you call this agent on your WQO event, maybe with some logic based on whether the agent should be called/your hitcounter go up, etc. (maybe if you, the admins, etc. are logged in you don't want to increment the counter field, or something like that...).

Instead, created a Computed For Display (CFD) field called "hitcounter" and set the value to FIELD counter := (counter + 1). Now, either place this field at the top of your forms, or (for the logic-based call) a computed subform that is only called when you want the hitcounter to run (for this example, I typically have two separate subforms for admins and users anyway, and would include this CFD field on the user subform).

This not only cuts down on the size of the database (as I would imagine but would have to doublecheck that an agent element is larger than a shared field, due to the sheer magnitude of what an agent can do...), but still allows you to change a single design element and effect multiple instances of it's usage.

A perfect example of this could be a workflow application that's conditionally loading a subform - instead of conditionally loading a subform AND checking the applications logic to see if the WQO agent should execute, simply include the CFD field on the called subform and take the logic out of the equation!