[docs] xmldocs - docelic modified 23 files
docs at icdevgroup.org
docs at icdevgroup.org
Thu Jun 9 08:02:45 EDT 2005
User: docelic
Date: 2005-06-09 12:02:44 GMT
Modified: . Makefile TODO
Modified: bin refs-autogen
Modified: glossary ActionMap form-action scratch
Modified: refs ActionMap Catalog SessionDatabase TcpHost TrackFile
Modified: Variable commify.filter date2time.filter
Added: refs CodeDef FormAction GlobalSub Profiles Sub
Added: SubCatalog TrustProxy UserDB UserTag
Log:
- 6 new config directives
- fixes to other files
Revision Changes Path
1.63 +10 -10 xmldocs/Makefile
rev 1.63, prev_rev 1.62
Index: Makefile
===================================================================
RCS file: /var/cvs/xmldocs/Makefile,v
retrieving revision 1.62
retrieving revision 1.63
diff -u -r1.62 -r1.63
--- Makefile 29 May 2005 11:19:33 -0000 1.62
+++ Makefile 9 Jun 2005 12:02:43 -0000 1.63
@@ -121,6 +121,7 @@
#############################################################
# STANDARD TARGETS || two-pass processing method
+#OUTPUT/howtos.html: DEPTH = "--stringparam toc.max.depth 1"
OUTPUT/%.html: %.xml docbook/autorefs.ent docbook/autoglossary.ent docbook/autohowtos.ent skel
echo "C $@"
$(PSR) $(PSR_FLAGS) \
@@ -145,15 +146,6 @@
--stringparam current.docid $* \
--stringparam target.database.document ../docbook/olinkdb-nc.xml \
-o $@/ docbook/html-chunks.xsl $T/$*-c.profiled
-
-
-
-### ALPHA SUPPORT FOR PDF
-#
-# --stringparam passivetex.extensions 1
-# --stringparam rootid "using"
-#
-
#$O/%.pdf: %.xml docbook/autorefs.ent docbook/autoglossary.ent docbook/autohowtos.ent skel
# echo "C $@"
# $(PSR) $(PSR_FLAGS) \
@@ -172,7 +164,15 @@
# --stringparam appendix.autolabel 0 \
# --stringparam section.autolabel 0 \
# -o $T/$*.fo docbook/fo.xsl $T/$*-nc.profiled
-# fop.sh -fo myfile.fo -pdf myfile.pdf
+# #fop.sh -fo myfile.fo -pdf myfile.pdf
+#
+#
+# --stringparam passivetex.extensions 1
+# --stringparam rootid "using"
+#
+
+
+
1.70 +1 -0 xmldocs/TODO
rev 1.70, prev_rev 1.69
Index: TODO
===================================================================
RCS file: /var/cvs/xmldocs/TODO,v
retrieving revision 1.69
retrieving revision 1.70
diff -u -r1.69 -r1.70
--- TODO 29 May 2005 11:19:33 -0000 1.69
+++ TODO 9 Jun 2005 12:02:43 -0000 1.70
@@ -1,5 +1,6 @@
Outstanding:
=======
+- At least in filters, <<EOR messes up the thing, only < is printed and stops
On config directives, include parse_<> function in source context
- See that if 'crypt' is put in see also, all symbols of that name appear
in see also line and their type is distinguished visually.
1.86 +2 -2 xmldocs/bin/refs-autogen
rev 1.86, prev_rev 1.85
Index: refs-autogen
===================================================================
RCS file: /var/cvs/xmldocs/bin/refs-autogen,v
retrieving revision 1.85
retrieving revision 1.86
diff -u -r1.85 -r1.86
--- refs-autogen 29 May 2005 11:19:33 -0000 1.85
+++ refs-autogen 9 Jun 2005 12:02:43 -0000 1.86
@@ -682,7 +682,7 @@
<partintro>
<para>
- <phrase condition='online'>[restrict log=none]</phrase>
+ <phrase condition='online'>[restrict log='none']</phrase>
$preamble{$group}
</para>
</partintro>
@@ -997,7 +997,7 @@
<phrase condition='online'>
[/restrict]
$code
-[restrict]
+[restrict log='none']
</phrase>
</textobject>
</programlisting>
1.4 +168 -0 xmldocs/glossary/ActionMap
rev 1.4, prev_rev 1.3
Index: ActionMap
===================================================================
RCS file: /var/cvs/xmldocs/glossary/ActionMap,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ActionMap 15 Dec 2004 14:24:00 -0000 1.3
+++ ActionMap 9 Jun 2005 12:02:43 -0000 1.4
@@ -1 +1,169 @@
The standard process action has a number of associated FormAction settings. Besides using Perl, Interchange tags may be used in an action, though they are not nearly as efficient.
+
+Some of the predefined actions (which you might recognize from special
+page names that you access in your catalog) are:
+<itemizedlist>
+<listitem><para>
+<literal>process</literal> - Perform a processing function
+</para></listitem>
+<listitem><para>
+<literal>order</literal> - Order items
+</para></listitem>
+<listitem><para>
+<literal>scan</literal> - Search based on path info
+</para></listitem>
+<listitem><para>
+<literal>search</literal> - Search based on submitted form variables
+</para></listitem>
+</itemizedlist>
+
+
+<!--
+TODO format
+Interchange form processing is based on an C<action> and a C<todo>. The
+predefined actions at the first level are:
+
+ process process a todo
+ search form-based search
+ scan path-based search
+ order order an item
+ minimate get access to a database via MiniMate
+
+You can define any action you desire with C<ActionMap>.
+
+The C<process> action has a second C<todo> level called with C<mv_todo>
+or C<mv_doit>. The C<mv_todo> takes preference over C<mv_doit>, which
+can be used to set a default if no C<mv_todo> is set.
+
+The action can be specified either with:
+
+=over 4
+
+=item page name
+
+Calling the page "search" will cause the search action, C<process>
+will cause a form process action, etc. Examples:
+
+ <FORM ACTION="/cgi-bin/simple/search" METHOD=POST>
+ <INPUT NAME=mv_searchspec>
+ </FORM>
+
+The above is a complete search in Interchange - it causes a simple text
+search of the default products database(s). Normally you don't use
+hard-coded paths, but use a minivend tag to specify it for portability:
+
+ <FORM ACTION="[area search]" METHOD=POST>
+ <INPUT NAME=mv_searchspec>
+ </FORM>
+
+You will often see the tag C<[process]> in Interchange forms. The above
+can be called equivalently with:
+
+ <FORM ACTION="[process]" METHOD=POST>
+ <INPUT TYPE=hidden NAME=mv_todo VALUE=search>
+ <INPUT NAME=mv_searchspec>
+ </FORM>
+
+=item mv_action
+
+Setting the special variable C<mv_action> causes the page name to
+be ignored as the action source. The above forms can use this as
+a synonym:
+
+ <FORM ACTION="[area foo]" METHOD=post>
+ <INPUT TYPE=hidden NAME=mv_action VALUE=search>
+ <INPUT NAME=mv_searchspec>
+ </FORM>
+
+The page name will be used to set C<mv_nextpage> if it is not
+otherwise defined; if C<mv_nextpage> is present in the form it
+will be ignored.
+
+=back
+
+The second level C<todo> for the C<process> action has these
+defined by default:
+
+ search Trigger a search
+ submit submit a form for validation (and possibly a final order)
+ go Go to C<mv_nextpage>
+ return Go to C<mv_nextpage>
+ set Update a database table
+ refresh Go to C<mv_orderpage|mv_nextpage> and check for
+ ordered items
+ cancel Erase the user session
+
+If you define a page name as an action with C<ActionMap>, or use
+of Interchange's predefined action C<process>, it will cause form processing.
+first level is setting the special page name C<process>, or speciis set to do a form C<process>, the for
+Interchange form can be used for any number of actions. The actions
+are mapped by the I<ActionMap> directive in the catalog configuration
+file, and are selected on the form with either the F<mv_todo> or F<mv_doit>
+variables.
+
+To set a default action for a C<process> form, set the variable C<mv_doit> as
+a hidden variable:
+
+ <INPUT TYPE=hidden NAME=mv_doit VALUE=refresh>
+
+When the F<mv_todo> value is not found, the I<refresh> action defined
+in F<mv_doit> will be used instead.
+
+More on the defined actions:
+
+=over 4
+
+=item cancel
+
+All user information is erased, and the shopping cart is emptied. The
+user is then sent to mv_nextpage.
+
+=item refresh
+
+Checks for newly-ordered items in C<mv_order_item>, looking for on-the-fly
+items if that is defined, then updates the shopping cart with any changed
+quantities or options. Finally updates the user variables and returns
+to the page defined in mv_orderpage or mv_nextpage (in that order of
+preference).
+
+=item return
+
+Updates the user variables and returns to the page defined
+in mv_nextpage.
+
+=item search
+
+The shopping cart and user variables are updated, then the form
+variables are interpreted and the search specification contained
+therein is dispatched to the search engine - results are returned
+on the defined search page (set by F<mv_search_page> or the search
+page directives).
+
+=item submit
+
+Submit the form for order processing. If no order profile is defined
+with the C<mv_order_profile> variable, the order is checked to see
+if the current cart contains any items and the order is submitted.
+
+If there is an order profile defined, the form will be checked against
+the definition in the order profile and submitted if the pragma &final
+is set to B<yes>. If &final is set to B<no> (the default), and the
+check succeeds, the user will be routed to the Interchange page defined in
+mv_successpage, or mv_nextpage. Finally, if the check fails, the user
+will be routed to mv_failpage or mv_nextpage in that order.
+
+=back
+
+
+When the leading part of the incoming path is equal to C<order>, it will trigger an action. The page name will be shifted up, and the C<order> stripped from the page name. So this custom C<order> action would essentially perform a no-op, and a URL like:
+
+!block example
+ <A HREF="[area order/nextpage]"> Go to the next page </A>
+ !endblock
+
+ would be the equivalent of "[area nextpage]." If the action does not return a true (non-zero, non-blank) status, no page will be displayed by Interchange, not even the special C<missing> page. A response may also be generated via Perl or MVASP.
+
+ The standard C<process> action has a number of associated C<FormAction> settings. Besides using Perl, Interchange tags may be used in an action, though they are not nearly as efficient.
+
+-->
+
1.4 +10 -154 xmldocs/glossary/form-action
rev 1.4, prev_rev 1.3
Index: form-action
===================================================================
RCS file: /var/cvs/xmldocs/glossary/form-action,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- form-action 18 Feb 2005 00:28:07 -0000 1.3
+++ form-action 9 Jun 2005 12:02:43 -0000 1.4
@@ -1,154 +1,10 @@
-Some of the predefined actions (which you might recognize from special
-page names that you access in your catalog) are:
-<itemizedlist>
-<listitem><para>
-<literal>process</literal> - Perform a processing function
-</para></listitem>
-<listitem><para>
-<literal>order</literal> - Order items
-</para></listitem>
-<listitem><para>
-<literal>scan</literal> - Search based on path info
-</para></listitem>
-<listitem><para>
-<literal>search</literal> - Search based on submitted form variables
-</para></listitem>
-</itemizedlist>
-
-
-<!--
-TODO format
-Interchange form processing is based on an C<action> and a C<todo>. The
-predefined actions at the first level are:
-
- process process a todo
- search form-based search
- scan path-based search
- order order an item
- minimate get access to a database via MiniMate
-
-You can define any action you desire with C<ActionMap>.
-
-The C<process> action has a second C<todo> level called with C<mv_todo>
-or C<mv_doit>. The C<mv_todo> takes preference over C<mv_doit>, which
-can be used to set a default if no C<mv_todo> is set.
-
-The action can be specified either with:
-
-=over 4
-
-=item page name
-
-Calling the page "search" will cause the search action, C<process>
-will cause a form process action, etc. Examples:
-
- <FORM ACTION="/cgi-bin/simple/search" METHOD=POST>
- <INPUT NAME=mv_searchspec>
- </FORM>
-
-The above is a complete search in Interchange - it causes a simple text
-search of the default products database(s). Normally you don't use
-hard-coded paths, but use a minivend tag to specify it for portability:
-
- <FORM ACTION="[area search]" METHOD=POST>
- <INPUT NAME=mv_searchspec>
- </FORM>
-
-You will often see the tag C<[process]> in Interchange forms. The above
-can be called equivalently with:
-
- <FORM ACTION="[process]" METHOD=POST>
- <INPUT TYPE=hidden NAME=mv_todo VALUE=search>
- <INPUT NAME=mv_searchspec>
- </FORM>
-
-=item mv_action
-
-Setting the special variable C<mv_action> causes the page name to
-be ignored as the action source. The above forms can use this as
-a synonym:
-
- <FORM ACTION="[area foo]" METHOD=post>
- <INPUT TYPE=hidden NAME=mv_action VALUE=search>
- <INPUT NAME=mv_searchspec>
- </FORM>
-
-The page name will be used to set C<mv_nextpage> if it is not
-otherwise defined; if C<mv_nextpage> is present in the form it
-will be ignored.
-
-=back
-
-The second level C<todo> for the C<process> action has these
-defined by default:
-
- search Trigger a search
- submit submit a form for validation (and possibly a final order)
- go Go to C<mv_nextpage>
- return Go to C<mv_nextpage>
- set Update a database table
- refresh Go to C<mv_orderpage|mv_nextpage> and check for
- ordered items
- cancel Erase the user session
-
-If you define a page name as an action with C<ActionMap>, or use
-of Interchange's predefined action C<process>, it will cause form processing.
-first level is setting the special page name C<process>, or speciis set to do a form C<process>, the for
-Interchange form can be used for any number of actions. The actions
-are mapped by the I<ActionMap> directive in the catalog configuration
-file, and are selected on the form with either the F<mv_todo> or F<mv_doit>
-variables.
-
-To set a default action for a C<process> form, set the variable C<mv_doit> as
-a hidden variable:
-
- <INPUT TYPE=hidden NAME=mv_doit VALUE=refresh>
-
-When the F<mv_todo> value is not found, the I<refresh> action defined
-in F<mv_doit> will be used instead.
-
-More on the defined actions:
-
-=over 4
-
-=item cancel
-
-All user information is erased, and the shopping cart is emptied. The
-user is then sent to mv_nextpage.
-
-=item refresh
-
-Checks for newly-ordered items in C<mv_order_item>, looking for on-the-fly
-items if that is defined, then updates the shopping cart with any changed
-quantities or options. Finally updates the user variables and returns
-to the page defined in mv_orderpage or mv_nextpage (in that order of
-preference).
-
-=item return
-
-Updates the user variables and returns to the page defined
-in mv_nextpage.
-
-=item search
-
-The shopping cart and user variables are updated, then the form
-variables are interpreted and the search specification contained
-therein is dispatched to the search engine - results are returned
-on the defined search page (set by F<mv_search_page> or the search
-page directives).
-
-=item submit
-
-Submit the form for order processing. If no order profile is defined
-with the C<mv_order_profile> variable, the order is checked to see
-if the current cart contains any items and the order is submitted.
-
-If there is an order profile defined, the form will be checked against
-the definition in the order profile and submitted if the pragma &final
-is set to B<yes>. If &final is set to B<no> (the default), and the
-check succeeds, the user will be routed to the Interchange page defined in
-mv_successpage, or mv_nextpage. Finally, if the check fails, the user
-will be routed to mv_failpage or mv_nextpage in that order.
-
-=back
--->
+&IC; "form actions" are basically &PERL; subroutine definitions that you can
+execute upon form submission. Which form action to trigger is specified by the
+<mv>mv_action</mv> form variable.
+</para><para>
+Successfully executed form action should return a &glos-true; value, upon
+which &IC; would display the page specified in <mv>mv_nextpage</mv>.
+If the form action returns &glos-false;, &IC; will not display any page.
+</para><para>
+Using &conf-FormAction;, you can both define new and override existing
+form actions.
1.3 +4 -0 xmldocs/glossary/scratch
rev 1.3, prev_rev 1.2
Index: scratch
===================================================================
RCS file: /var/cvs/xmldocs/glossary/scratch,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- scratch 15 Dec 2004 14:24:00 -0000 1.2
+++ scratch 9 Jun 2005 12:02:43 -0000 1.3
@@ -21,3 +21,7 @@
<para>
Scratch variables are also used in form processing. See the
<tag>button</tag> tag for examples.
+
+
+<!--
+howto define/call scratch sub -->
1.3 +10 -7 xmldocs/refs/ActionMap
rev 1.3, prev_rev 1.2
Index: ActionMap
===================================================================
RCS file: /var/cvs/xmldocs/refs/ActionMap,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ActionMap 18 Feb 2005 00:28:07 -0000 1.2
+++ ActionMap 9 Jun 2005 12:02:43 -0000 1.3
@@ -1,7 +1,5 @@
-UNVERIFIED
-
__NAME__ purpose
-modify or define custom Interchange form actions
+modify or define custom Interchange actions
__END__
@@ -19,11 +17,16 @@
__NAME__ description
-The directive allows the definition of &IC; form actions, and its content is
-usually with a &PERL; subroutine.
+The directive allows the definition of Interchange &glos-ActionMap;s, whose
+contents are usually &PERL; subroutines.
</para><para>
-For an introduction to Action Maps, see &glos-form-action;s glossary
-entry.
+The leading part of the incoming page path is taken and checked if it represents
+a valid action. If it does, the action name itself will be stripped from the
+path, and the appropriate action will be called with the rest of the argument.
+__END__
+
+__NAME__ notes
+For an introduction to Action Maps, see &glos-ActionMap; glossary entry.
__END__
1.4 +8 -5 xmldocs/refs/Catalog
rev 1.4, prev_rev 1.3
Index: Catalog
===================================================================
RCS file: /var/cvs/xmldocs/refs/Catalog,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Catalog 20 May 2005 21:41:49 -0000 1.3
+++ Catalog 9 Jun 2005 12:02:43 -0000 1.4
@@ -14,26 +14,28 @@
__NAME__ description
-The directive registers a catalog that will run on the corresponding &IC;
+The directive registers a &glos-catalog; that will run on the corresponding &IC;
installation.
</para><para>
The directive expects three or more arguments.
</para><para>
-First expected is the name of the catalog. It will be referred to by the specified
+First expected is the name of the &glos-catalog;. It will be referred to by the specified
name in error, warning, and informational messages. It must contain only
alphanumeric characters, hyphens, and underscores. It is highly recommended that
it is also all lowercase.
</para><para>
Second argument specifies the local filesystem base directory of the catalog.
If the directory does not exist, the required &ccf; is not there, or &IC;
-detects any other problem, catalog configuration will be skipped and the catalog
+detects any other problem, catalog configuration will be skipped and the
+&glos-catalog;
won't be activated.
</para><para>
Third argument is the so called <literal>SCRIPT_NAME</literal> of the
&glos-link-program;. It is a webserver path by which the catalog can be
accessed. It can be followed by different
<emphasis role='bold'>aliases</emphasis>, all allowing you to access
-the same catalog. For example, this is useful when calling an SSL server or a
+the same &glos-catalog;. For example, this is useful when calling an SSL
+server or a
members-only alias that requires a Basic HTTP authorization using the
username/password pair. All subsequently generated links would be called using
the aliased URL.
@@ -50,7 +52,8 @@
__NAME__ notes
&conf-Catalog; is one of the basic Interchange &glos-configuration; directives.
</para><para>
-<command>makecat</command>, the catalog creation helper script, automatically inserts
+<command>makecat</command>, the &glos-catalog; creation helper script,
+automatically inserts
the &conf-Catalog; line in the &gcf; file as part of the standard procedure.
</para><para>
If the &ccf; file, expected in the catalog base directory, is not found, or is
1.3 +1 -1 xmldocs/refs/SessionDatabase
rev 1.3, prev_rev 1.2
Index: SessionDatabase
===================================================================
RCS file: /var/cvs/xmldocs/refs/SessionDatabase,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SessionDatabase 8 Dec 2004 12:39:58 -0000 1.2
+++ SessionDatabase 9 Jun 2005 12:02:43 -0000 1.3
@@ -5,7 +5,7 @@
__NAME__ synopsis
<group choice='req'>
- <arg choice='plain'>filename or directory</arg>
+ <arg choice='plain'>filename_or_directory</arg>
</group>
__END__
1.2 +1 -1 xmldocs/refs/TcpHost
rev 1.2, prev_rev 1.1
Index: TcpHost
===================================================================
RCS file: /var/cvs/xmldocs/refs/TcpHost,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TcpHost 21 Feb 2005 01:16:51 -0000 1.1
+++ TcpHost 9 Jun 2005 12:02:44 -0000 1.2
@@ -36,7 +36,7 @@
__NAME__ example: Defining TcpHost
<programlisting><![CDATA[
-TcpHost localhost secure.domain.com
+TcpHost localhost secure.domain.com 192.168.8.9
]]></programlisting>
__END__
1.3 +5 -3 xmldocs/refs/TrackFile
rev 1.3, prev_rev 1.2
Index: TrackFile
===================================================================
RCS file: /var/cvs/xmldocs/refs/TrackFile,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TrackFile 2 Feb 2005 11:35:58 -0000 1.2
+++ TrackFile 9 Jun 2005 12:02:44 -0000 1.3
@@ -15,9 +15,11 @@
</para><para>
User &glos-tracking; can be used in back office administration to summarize
traffic by affiliates.
-</para><para>
-The Interchange daemon must have the permission to create and write to the
-specified file.
+__END__
+
+__NAME__ notes
+The &IC; daemon must have the permission to create and write to the
+specified file, of course.
__END__
__NAME__ example: Setting TrackFile
1.5 +6 -1 xmldocs/refs/Variable
rev 1.5, prev_rev 1.4
Index: Variable
===================================================================
RCS file: /var/cvs/xmldocs/refs/Variable,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Variable 8 Dec 2004 12:39:58 -0000 1.4
+++ Variable 9 Jun 2005 12:02:44 -0000 1.5
@@ -49,9 +49,14 @@
__NAME__ example: Defining a variable
-Put the following in &ccf;:
<programlisting>
Variable EMAIL root@&def-domain;
+</programlisting>
+__END__
+
+__NAME__ example: Defining a variable
+<programlisting>
+Variable DOCUMENT_ROOT /usr/local/etc/httpd/htdocs
</programlisting>
__END__
1.2 +5 -0 xmldocs/refs/commify.filter
rev 1.2, prev_rev 1.1
Index: commify.filter
===================================================================
RCS file: /var/cvs/xmldocs/refs/commify.filter,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- commify.filter 22 Dec 2004 14:06:37 -0000 1.1
+++ commify.filter 9 Jun 2005 12:02:44 -0000 1.2
@@ -18,3 +18,8 @@
</programlisting>
__END__
+
+__NAME__ missing
+Why 12345.6789 with [filter commify.2] becomes 0.67 ?
+__END__
+
1.2 +5 -0 xmldocs/refs/date2time.filter
rev 1.2, prev_rev 1.1
Index: date2time.filter
===================================================================
RCS file: /var/cvs/xmldocs/refs/date2time.filter,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- date2time.filter 29 May 2005 15:01:39 -0000 1.1
+++ date2time.filter 9 Jun 2005 12:02:44 -0000 1.2
@@ -47,3 +47,8 @@
[filter date2time]01-01-05:1045[/filter] <br/>
]]></programlisting>
__END__
+
+
+__NAME__ missing
+look at online examples, they dont seem healthy
+__END__
1.1 xmldocs/refs/CodeDef
rev 1.1, prev_rev 1.0
Index: CodeDef
===================================================================
__NAME__ purpose
generic subroutine mapper
__END__
__NAME__ see also
CodeDef,UserTag,Filter,ActionMap,FormAction,GlobalSub,ItemAction,CoreTag
__END__
_NAME__ synopsis
<group choice='req'>
<arg choice='plain'>
<literal>Sub</literal>
<replaceable>perl_code</replaceable>
</arg>
</group>
_END__
__NAME__ description
A generic &PERL; subroutine mapper which allows mapping of subroutines to
&glos-ActionMap;s,
CoreTags, &conf-UserTag;s,
&glos-Filter;s,
&glos-form-action;s,
&conf-GlobalSub;s,
ItemActions,
LocaleChanges and
OrderChecks.
__END__
_NAME__ example: Defining a subroutine
_END__
__NAME__ notes
__END__
__NAME__ missing
PORT_OLD
__END__
1.1 xmldocs/refs/FormAction
rev 1.1, prev_rev 1.0
Index: FormAction
===================================================================
__NAME__ purpose
define form action (such as existing 'return', 'submit' or 'refresh')
__END__
__NAME__ see also
CodeDef,UserTag
__END__
__NAME__ synopsis
<group choice='req'>
<arg choice='plain'>
<replaceable>action_name</replaceable>
<replaceable>perl_code</replaceable>
</arg>
</group>
__END__
__NAME__ description
The directive allows definition of &glos-form-action;s. Some pre-defined
actions that you might already be familiar with are
<literal>return</literal>,
<literal>submit</literal> or
<literal>refresh</literal>.
__END__
__NAME__ example: Very basic form action definition
<programlisting><![CDATA[
FormAction foo <<EOR
sub {
$CGI->{mv_nextpage} = 'bar';
}
EOR
]]></programlisting>
To invoke this form action, use the following HTML form:
<programlisting><![CDATA[
]]></programlisting>
__END__
__NAME__ notes
Catalog version of the directive is protected by <classname>Safe</classname>.
</para><para>
For a complete discussion, please see the &glos-form-action; glossary entry.
__END__
__NAME__ missing
check if basic example works, and add a form that triggers the action
PORT_OLD
__END__
1.1 xmldocs/refs/GlobalSub
rev 1.1, prev_rev 1.0
Index: GlobalSub
===================================================================
__NAME__ purpose
define global Perl functions for use within Interchange
__END__
__NAME__ see also
CodeDef,Sub,AllowGlobal
__END__
__NAME__ synopsis
<group choice='req'>
<arg choice='plain'>
<literal>Sub</literal>
<replaceable>perl_code</replaceable>
</arg>
</group>
__END__
__NAME__ description
Define a global subroutine for use within &tag-perl;, &tag-mvasp;, or
embedded &PERL; languages.
</para><para>
The use of "here document" syntax in &IC; makes subroutine definitions
visually convenient.
__END__
__NAME__ example: Defining a global subroutine
<programlisting><![CDATA[
GlobalSub <<EOF
sub count_orders {
my $counter = new File::CounterFile "/tmp/count_orders", '1';
my $number = $counter->inc();
return "There have been $number orders placed.\n";
}
EOF
]]></programlisting>
The above code would be called from an &IC; page in the following way:
<programlisting><![CDATA[
Items, sorted by quantity:
[perl tables=products subs='sort_cart_by_quantity']
my $cart = $Carts->{main};
return sort_cart_by_quantity($cart);
[/perl]
]]></programlisting>
__END__
__NAME__ notes
As with &PERL; "here documents," the "<literal>EOF</literal>" (or arbitrarily
named end marker) must be the <emphasis>only</emphasis> thing on the line,
without leading or trailing white space. Do not even append a semicolon to the
marker (as you would in &PERL;).
</para><para>
Global subroutines are not subject to <classname>Safe</classname> security
checks. Therefore, &glos-scratch; or catalog subroutines (&conf-Sub;s) are
preferred in most cases.
__END__
__NAME__ missing
Example isn't working? Sub gets called, but doesnt sort!
PORT_OLD
__END__
1.1 xmldocs/refs/Profiles
rev 1.1, prev_rev 1.0
Index: Profiles
===================================================================
__NAME__ purpose
specify files containing OrderProfile and SearchProfile definitions
__END__
__NAME__ missing
Add self-contained profile example
PORT_OLD
__END__
__NAME__ see also
__END__
__NAME__ synopsis
<group choice='req'>
<arg choice='plain' rep='repeat'><replaceable>filename</replaceable></arg>
</group>
__END__
__NAME__ description
Specify filenames that contain &conf-OrderProfile; and &conf-SearchProfile;
definitions.
__END__
__NAME__ notes
For the complete discussion, please see the &glos-profile; glossary entry.
__END__
__NAME__ example: Defining Profiles
<programlisting>
Profiles etc/profiles.common etc/profiles.login
</programlisting>
__END__
1.1 xmldocs/refs/Sub
rev 1.1, prev_rev 1.0
Index: Sub
===================================================================
__NAME__ purpose
define Perl functions for use within a catalog
__END__
__NAME__ see also
CodeDef,UserTag,AllowGlobal
__END__
__NAME__ synopsis
<group choice='req'>
<arg choice='plain'>
<replaceable>perl_code</replaceable>
</arg>
</group>
__END__
__NAME__ description
Define a catalog subroutine for use within &tag-perl;, &tag-mvasp;, or
embedded &PERL; languages.
</para><para>
The use of "here document" syntax in &IC; makes subroutine definitions
visually convenient.
__END__
__NAME__ example: Defining a subroutine
<programlisting><![CDATA[
Sub <<EOF
sub sort_cart_by_quantity {
my($items) = @_;
$items = $Items if ! $items;
my $out = '<table border="1">';
@$items = sort { $a->{quantity} <=> $b->{quantity} } @$items;
foreach $item (@$items) {
my $code = $item->{code};
$out .= '<tr><td>';
$out .= $code;
$out .= '</td><td>';
$out .= $Tag->data('products', 'name', $code);
$out .= '</td><td>';
$out .= $Tag->data('products', 'price', $code);
$out .= '</td></tr>';
}
$out .= '</table>';
return $out;
}
EOF
]]></programlisting>
The above code would be called from an &IC; page in the following way:
<programlisting><![CDATA[
Items, sorted by quantity:
[perl tables=products subs='sort_cart_by_quantity']
my $cart = $Carts->{main};
return sort_cart_by_quantity($cart);
[/perl]
]]></programlisting>
__END__
__NAME__ notes
As with &PERL; "here documents," the "<literal>EOF</literal>" (or arbitrarily
named end marker) must be the <emphasis>only</emphasis> thing on the line,
without leading or trailing white space. Do not even append a semicolon to the
marker (as you would in &PERL;).
</para><para>
Catalog subroutines may not perform unsafe operations. The
<classname>Safe</classname>
module enforces this unless global operations are allowed for the
catalog. See &glos-safe; glossary entry for more information.
__END__
__NAME__ missing
Example isn't working? Sub gets called, but doesnt sort!
__END__
1.1 xmldocs/refs/SubCatalog
rev 1.1, prev_rev 1.0
Index: SubCatalog
===================================================================
__NAME__ purpose
register subcatalog with the Interchange server
__END__
__NAME__ see also
FullUrl,Mall,Catalog
__END__
__NAME__ synopsis
<arg choice='plain'><replaceable>subcatalog_name</replaceable></arg>
<arg choice='plain'><replaceable>base_catalog_name</replaceable></arg>
<arg choice='plain'><replaceable>&glos-CATROOT;</replaceable></arg>
<arg choice='plain' rep='repeat'><replaceable>&glos-link-program;</replaceable></arg>
__END__
__NAME__ description
The directive allows definition of "subcatalogs" — &glos-catalog;s that
share most of the characteristics of
another, "base" catalog. Only the directives that are changed from the
base catalog are added.
</para><para>
&IC;'s subcatalogs feature isn't used much, but primary reasons for its use
would be memory savings, or some kind of chained-configuration catalogs.
__END__
__NAME__ notes
For a complete discussion, see &glos-catalog; glossary entry and the
&conf-Catalog; config directive.
__END__
__NAME__ example: Registering a sub catalog
<programlisting>
Catalog simple /home/catalogs/simple /cgi-bin/ic/simple
Catalog subsimple simple /home/catalogs/simple /cgi-bin/ic/subsimple
</programlisting>
__END__
__NAME__ missing
PORT_OLD
some concrete example, tested and working standalone
__END__
1.1 xmldocs/refs/TrustProxy
rev 1.1, prev_rev 1.0
Index: TrustProxy
===================================================================
__NAME__ purpose
designate certain IP addresses or hostnames as trusted HTTP proxies
__END__
__NAME__ see also
WideOpen,Mall,IpHead,IpQuad
__END__
__NAME__ synopsis
<group choice='req'>
<arg choice='plain' rep='repeat'><replaceable>hostname</replaceable></arg>
</group>
__END__
__NAME__ description
The directive
allows &IC; administrator to designate certain IP addresses or hostnames
as trusted HTTP proxies, whose claims (via the
<envar>HTTP_X_FORWARDED_FOR</envar>
environment variable set by the web server) about the original requesting
host will be assumed truthful and accurate.
</para><para>
For example, if you are using a front-end proxy for &IC;, all requests will
appear to come from the proxy address (say, <literal>127.0.0.1</literal> if
on the same machine). In turn, all clients will appear as having the same
source IP address (much like if you enabled &conf-WideOpen;). Under such
circumstances, user session hijacking becomes trivial enough that it can even
happen by accident (if, say, someone copies an URL that includes his/her
session cookie and gives it to others to visit — they all will end up
having the same user info and shopping cart!).
</para><para>
Having said the above, &conf-TrustProxy; takes a comma-separated list of
IP addresses and/or hostnames (globbing possible - see examples) that are
trusted proxies and whose value of <envar>HTTP_X_FORWARDED_FOR</envar>
should be used as request source instead of the actual IP directly.
__END__
__NAME__ notes
"Globs" are <literal>*</literal> and <literal>?</literal>. The
<literal>*</literal> stands for any number of characters (including 0), while
<literal>?</literal> stands for 1 character exactly.
</para><para>
The directive could, in general, be also used with external, untrusted HTTP
proxies (which you can only hope aren't lying) by using a <literal>*</literal>
glob (see examples).
</para><para>
Note that the environment variables are not modified in any way; only
&IC;'s idea of the remote host is altered, as you see with
<code>[data session host]</code>.
__END__
__NAME__ missing
PORT_OLD
__END__
__NAME__ example: Defining TrustProxy
<programlisting>
TrustProxy 127.0.0.1 192.168.8.4
</programlisting>
__END__
__NAME__ example: Defining TrustProxy with "glob" values
<programlisting>
TrustProxy 127.0.0.? 10.0.* 192.168.?.1
</programlisting>
__END__
__NAME__ example: Trusting all external proxies (a bad idea generally)
<programlisting>
TrustProxy *
</programlisting>
__END__
1.1 xmldocs/refs/UserDB
rev 1.1, prev_rev 1.0
Index: UserDB
===================================================================
__NAME__ purpose
adjust default behavior of Interchange user database functions
__END__
__NAME__ see also
Database,
__END__
__NAME__ synopsis
<!--
<arg choice='plain'><replaceable>NAME</replaceable></arg>
<arg choice='plain'><replaceable>value</replaceable></arg>
-->
__END__
__NAME__ description
The directive sets parameters to adjust the behavior of Interchange's
user database functions.
__END__
__NAME__ notes
See &glos-UserDB; glossary entry for more information.
__END__
!block table
Parameter|Default|Explanation
acl|acl|Set field for simple access control storage
addr_field|address_book|Set field name for address book
assign_username|0|Tell interchange to automatically assign username
bill_field|accounts|Set field name for accounts
cart_field|carts|Set field name for cart storage
clear_coookie||Comma-separated list of cookies to clear on explicit logout
clear_session||Clear user session completely on logout
counter||Counter file for assign_username function
crypt|1|Encrypt (1) or not encrypt (0) passwords
database|userdb|Sets user database table
db_acl|db_acl|Set field for database access control storage
expire_field|expiration|Set field for expiration date
file_acl|file_acl|Set field for file access control storage
force_lower|0|Force possibly upper-case database fields to lower case session variable names
ignore_case|0|Ignore case in usernames/passwords
indirect_login||Log in field if different than real username
logfile|error.log|File to log authentications/errors
md5|0|Use MD5 for encryption algorithm instead of crypt
no_get|0|Don't get values from database on login
no_login|0|Log people in to accounts even if they are already logged in
outboard_key_col||Set field providing key for outboard tables
outboard||Set fields that live in another table
pass_field|password|Set field name for password
passminlen|2|Minimum length for password
pref_field|preferences|Set field name for preferences
scratch||Fields to set in user Scratch space (instead of Values)
sql_counter||SQL counter spec (sequence or AUTO_INCREMENT) for assign_username function
super_field|super|Field to determine superuser status if admin profile
time_field|time|Set field for storing last login time
unix_time|0|Set if unix (seconds since 1970) time to go in log files
userminlen|2|Minimum length for username
username_mask||Regular expression usernames must not match
!endblock
These are set in a C<catalog.cfg> file with something like:
UserDB default crypt 0
UserDB admin crypt 1
UserDB admin md5 1
where C<default> or C<admin> is the name of the profile to set. These can
be overriden if passed in the tag:
> [userdb userminlen=6 new-account=1]
1.1 xmldocs/refs/UserTag
rev 1.1, prev_rev 1.0
Index: UserTag
===================================================================
__NAME__ purpose
define an Interchange tag
__END__
__NAME__ see also
CodeDef
__END__
__NAME__ synopsis
<!--
<arg choice='plain'><replaceable>NAME</replaceable></arg>
<arg choice='plain'><replaceable>value</replaceable></arg>
-->
__END__
_NAME__ description
_END__
__NAME__ notes
Catalog-based usertag will run under <classname>Safe</classname> restrictions
and will only be accessible from the corresponding catalog.
For many purposes, a global &conf-UserTag;s are better. They're not restricted
by <classname>Safe</classname> and are available to all catalogs running on
the server.
__END__
_NAME__ example: Defining a simple tag
_END__
More information about the docs
mailing list