-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathictags-more.txt
178 lines (126 loc) · 6.9 KB
/
ictags-more.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
To rework and include in ictags:
------------------------------------------------------------------------------
A2: How can I tell when I need to quote a tag inside a tag?
In general, you don't need to quote the following tags which are interpreted first within a list:
!block example
[item-code] [item-data ...] [item-field ...] etc.
[loop-code] [loop-data ...] [loop-field ...] etc.
[foo-code] [foo-data ...] [foo-field ...] etc.
!endblock
This is because they are interpreted as a part of the surrounding C<[loop]>, C<[item-list]>, C<[search-list]>, C<[sql list]>, or C<[tag each table]> constructs.
So this will work:
!block example
[item-list]
[page [item-field url]]detailed info[/page] on [item-description]
[/item-list]
!endblock
This will I<not> work:
!block example
[page [value mypage]]
!endblock
The [value ...] tag is not interpolated before page, and the parser will not know to do so. It needs to be instead:
!block example
[page href="[value mypage]"]
!endblock
You might wonder why unquoted tags are even allowed. The answer is performance. If you have large lists of tags you can achieve significant speedups by using positional parameters. It requires CPU power to parse and disassemble the named parameters.
------------------------------------------------------------------------------
LI1: [page ...]
.If the user has sent a cookie to Interchange (meaning the second page they access), and the scratch value C<mv_no_session_id> is set in their session, the session ID will not be appended to the URL. If the scratch value C<mv_no_count> is set, then the page count will not be appended. This is not dependent on cookies. So, if placed in the initial page:
!block example; listitem=2
[set mv_no_session_id]1[/set]
[set mv_no_count]1[/set]
[set mv_add_dot_html]1[/set]
!endblock
.or put in C<catalog.cfg>:
!block example; listitem=2
ScratchDefault mv_no_session_id 1
ScratchDefault mv_no_count 1
ScratchDefault mv_add_dot_html 1
!endblock
.No session ID or count will be shown. That makes the URL shown above to be http://machine.company.com/cgi-bin/vlink/shirts.html. Once again, this is on the second page the user accesses, if they are taking and sending cookies. If the user has a pre-existing C<MV_SESSION_ID> or C<MV_USERNAME> cookie from a prior session, the effect will be immediate.
.The C<argument> will be passed to Interchange and placed in the C<mv_arg> session parameter. This allows programming of a conditional page display based on where the link came from. The argument is then available with the tag [data session arg], or the embedded Perl session variable $Session->{arg}. Spaces and some other characters will be escaped with the %NN URL-style notation and unescaped when the argument is read back into the session.
.A bit of magic occurs if Interchange has built a static plain HTML page for the target page. Instead of generating a normal Interchange-parsed page reference, a static page reference will be inserted if the user has accepted and sent back a cookie with the session ID.
H2: Accessing Form Values
When a form is sent to Interchange, the program reads the values and places them in the user session. The following form:
!block example; listitem=2
<FORM ACTION="[area index]" METHOD=POST>
<INPUT TYPE=hidden NAME=mv_action VALUE=return>
<INPUT TYPE=hidden NAME=foo VALUE=bar>
<INPUT TYPE=submit NAME="Make foo=bar">
</FORM>
!endblock
will make the C<[value foo]> tag equal to C<bar> on the next page, then, send you to the page C<index>(.html). Same for this link:
!block example; listitem=2
<A HREF="[area href=index
form='
foo=bar
mv_action=return
']">Make foo=bar</A>
!endblock
LI1: [value name=field set="new value" filter="filter" hide=1]
.\Positional: C<[value varname]>
.The C<[value ...]> ITL tag expands into the current value of the customer/form input field named by field. If the C<set> value is present, the form variable value will be set to it and the new value returned. Use this to "uncheck" a checkbox or set other form variable values to defaults. If C<HIDE> is set, the value will be set but not returned to the page.
.The C<filter="filter1 filter1"> parameter applies any of the standard Interchange filter types to the value. See C<Filters>. When the value is returned, any Interchange tags present in the value will be escaped. This prevents users from entering Interchange tags in form values, which could be a serious security risk.
------------------------------------------------------------------------------
Date: Wed, 11 Oct 2000 08:10:02 -0400
From: Mike Heins <mikeh@minivend.com>
To: alison@akopia.com, tech@akopia.com
Subject: Re: Tag reference issues...
Quoting Jeff Barr Akopia" (barr@akopia.com):
> 2. "-" / "_" in tag names. Let's standardize on
> "-" and note that "_" is a worthy alternative.
> (Fixing this everywhere is too big of a job
> for this release).
Also, note that when using tags in embedded Perl the underscore is
required, i.e. $Tag->total-cost could not work. Any real Perl programmer
would know that, but some of our users may not.
>
> 3. Discount-subtotal Tag
> [discount-subtotal]
>
> Expands into the discounted subtotal cost, exclusive of sales tax,
> of all the items ordered so far.
This is the subtotal for the current line of the shopping cart, not
the order as a whole. The [subtotal] tag always reflects discounts.
Actually, this is probably an inconsistency that could be corrected
some time. IT really should be PREFIX-discount-subtotal. We would have
to deprecate, though, as there are plenty of implementations which
use this. 4.7 stuff.
>
> 4. Some deprecated tags (we may want to have a list of these in one
> place):
>
> - [region] is deprecated; [search-region] is preferred.
Yes. No mention need be made of it in the docs.
> - [on_match] is deprecated.
No. This should really be made PREFIX-on-match or on-PREFIX-match,
as above, but it is not deprecated.
> - [sql] is deprecated.
Yes. No mention need be made of it in the docs.
>
> 6. [tag time] should be changed to [time].
Yes, but we need to document the options.
>
> 7. Fly_tax Tag
>
> [fly_tax]
>
> (Mike -- need some help here. What does this tag do. The code
> is impenetrable.)
It builds a tax rate from TAXAREA, TAXRATE, TAXSHIPPING, variable values and
the SalesTax directive value. I didn't document it because I was hoping to get
rid of it before MV4.0 release. Obviously that didn't happen. There is action
at a distance as well -- the tag is really called in salestax.asc. It is kind
of a mess, and I would hope that we fix this for 4.7.
>
> 9. Filter Tag
>
> Longer-term, we need to have a complete document which describes
> the [filter] model. Can you put this on your list of things to do.
>
> 10. Handling Tag
>
> [handling]
>
> Calculates handling costs.
Yes, those shipmodes defined in mv_handling.