Tag syntax

MiniVend uses a style similar to HTML, but with [square brackets] replacing <chevrons>. The parameters that can be passed are much the same, where a parameter=``paramter value'' can be passed.

Summary:

    [tag parameter]             Tag called with positional parameter
    [tag parameter=value]       Tag called with named parameter
    [tag parameter="the value"] Tag called with space in parameter
    [tag 1 2 3]                 Tag called with multiple positional parameters
    [tag foo=1 bar=2 baz=3]     Tag called with multiple named parameters
    [tag foo=`2 + 2`]           Tag called with calculated parameter
    [tag foo="[value bar]"]     Tag called with tag inside parameter
    [tag foo="[value bar]"]
        Container text.         Container tag.
    [/tag]

Most tags can accept some positional parameters; this speeds up parsing and is simpler to write in many cases.

Here is an example tag:

    [value name=city]

That will cause MiniVend to look in the user form value array and return the value of the form parameter city, which might have been set with:

    City: <INPUT TYPE=text NAME=city VALUE="[value city]">

Note that we pre-set the value with the previous value of city (if any). It uses the positional style -- name is the first positional parameter for the [value ...] tag.

Positional parameters cannot be derived from other MiniVend tags; for instance [value [value formfield]] will not work. But if you use the named parameter syntax, the parameters can contain other tags, i.e.:

    [value name="[value formfield]"]

There is one exception to the above rule when using the [item-list], [loop ...], [sql ...], and other list tags. We will examine that in their individual sections.

Many MiniVend tags are container tags:

    [set Checkout]
        mv_nextpage=ord/checkout
        mv_todo=return
    [/set]

Tags and parameter names are not case sensitive, so [VALUE NAME=something] would work just as well. MiniVend convention is to place HTML tags in upper case and MiniVend tags in lower case so pages are easier to read, but you could easily reverse the sense.

Single quotes work just as well as double quotes, and can prevent ambiguity.

    [value name=b_city set='[value city]']

works just as well.

Backticks, the other single quote, cause the parameter contents to be evaluated as Perl code via the [calc] tag. (This is in MV3.15 and above.) So

    [value name=row_value set=`$row_value += 1`]

is the same as

    [value name=row_value set="[calc]$row_value += 1[/calc]"]

You can also specify constructs inside an HTML tag:

    <TABLE MV="if items">
    <TR MV="item-list">
    <TD> [item-code] </TD>
    <TD> [item-description] </TD>
    <TD> [item-price] </TD>
    </TR></TABLE>

The above will loop over any items in the shopping cart, displaying their part number, description, and price, but only IF there are items in the cart. It is equivalent to:

    [if items]
    <TABLE>
    [item-list]
    <TR>
    <TD> [item-code] </TD>
    <TD> [item-description] </TD>
    <TD> [item-price] </TD>
    </TR>
    [/item-list]
    </TABLE>
    [/if]

This is provided to allow HTML editors to work with MiniVend if they wish. One common tag that is best specified in this fashion is [body n], which would be best done as <BODY MV=``body 1''>.

What is done with the results of the tag depends on whether it is a container or standalone tag. A container tag is one which has an end tag, i.e. [tag] stuff [/tag]. A standalone tag has no end tag, as in [area href=somepage]. (Note that [page ...] and [order ..] are not container tags.)

A container tag will have its output re-parsed for more MiniVend tags by default. If you wish to inhibit this behavior, you must explicitly set the attribute reparse to 0. Note that you will almost always wish the default action.

With some exceptions ([include file] among them) the output of a standalone tag will not be re-interpreted for MiniVend tag constructs.

Most container tags will not have their contents interpreted before being passed the container text. Exceptions include [calc] .. [/calc] and [currency] ... [/currency]. All tags accept the INTERPOLATE=1 tag modifier, which causes the interpretation to take place. It is frequent that you will not want to interpret the contents of a [set variable] TAGS [/set] pair, as that might contain tags which should only be upon evaluating an order profile, search profile, or mv_click operation. If you wish to perform the evaluation at the time a variable is set, you would use [set name=variable interpolate=1] TAGS [/set].

Index Up >>

Tag syntax

Index Up >>