Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Persistents in condition statements are accessed in the same way as in the prelude.

For historical reasons, if the persistent variable does not exist before it is used, the default value is 0. 

This means that the isnull() operator, for example, is never true for an entity variable.

Examples

The following action will fire when the persistent variable ent:archive_pages is greater than 3:

if ent:archive_pages > 3 then 
notify(...)

Deprecated

Deprecated

The following are deprecated and should not be used. 

Persistent flags and counters can also be tested with an associated timeframe. For example, the following action will fire when persistent variable ent:archive_pages is greater than 3 and the last time it as set was within the last two hours:

if ent:archive_pages > 3 within 2 hours then
notify(...) 

The syntax of timeframe-limited predicates is as follows:

<pvar> (<= | >= | < | > | == | !=) <expr> 
   within <expr> (weeks| days| hours | minutes| seconds)

where <pvar> is a persistent flag or counter and <expr> is any valid KRL expression that returns a number.

Persistent trails can be tested using the seen predicate. There are two forms. The first form asks whether a regular expression has been seen within an optional timeframe (specified exactly as above). So, you can say:

if seen re#/archive/2006# in ent:my_trail then
  notify(...) 

or

if seen re#/archive/2006# in ent:my_trail within 3 days then
  notify(...) 

The second form of special predicates for trails allows for checking whether a match of one regular expression appears before an item matched by another. This example would fire the action when a place matching the regular expression re#/archive/2006# was put on the trail before a place matching the regular expression re#/archive/2007#.

if seen re#/archive/2006# before re#/archive/2007# in ent:my_trail then 
  notify(...) 

Note that before in the preceding conditional is not the same as the before operator in an eventex event though they share the same name.

  • No labels