[docs] xmldocs - docelic modified 8 files
docs at icdevgroup.org
docs at icdevgroup.org
Sat Jun 11 13:22:37 EDT 2005
User: docelic
Date: 2005-06-11 17:22:37 GMT
Modified: . TODO
Modified: glossary CGI session
Modified: refs EncryptProgram
Added: refs Filter FormIgnore FractionalItems History
Log:
- Some fixes and 4 new items
Revision Changes Path
1.73 +2 -0 xmldocs/TODO
rev 1.73, prev_rev 1.72
Index: TODO
===================================================================
RCS file: /var/cvs/xmldocs/TODO,v
retrieving revision 1.72
retrieving revision 1.73
diff -u -r1.72 -r1.73
--- TODO 11 Jun 2005 08:53:41 -0000 1.72
+++ TODO 11 Jun 2005 17:22:36 -0000 1.73
@@ -1,6 +1,8 @@
Outstanding:
=======
- across glossary entries, insert <section>s
+- import my hand-made test from /var/lib/.../pages/* to appropriate
+ ref pages as online examples
- At least in filters, <<EOR messes up the thing, only < is printed and stops
- bin/refs-autogen should report which refs/* files have comments in them
(text outside __NAME__ __END__ markers). It indicates there's a work to do
1.2 +10 -0 xmldocs/glossary/CGI
rev 1.2, prev_rev 1.1
Index: CGI
===================================================================
RCS file: /var/cvs/xmldocs/glossary/CGI,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- CGI 22 Dec 2004 00:14:20 -0000 1.1
+++ CGI 11 Jun 2005 17:22:36 -0000 1.2
@@ -28,3 +28,13 @@
great concern from a security standpoint.
<!-- TODO what to read on the topic -->
<!-- TODO: IC functionality to deal with CGI data security .. filters etc. -->
+<!--
+&IC; is, by default, eager to collect user information, at least for the
+duration of the session (so they don't have to retype it again).
+When a form is submitted, form values from the <emphasis>directly</emphasis>
+submitted form (and only values from the directly submitted form)
+are accessible by the &tag-cgi; tag. During processing, those variables
+are also propagated to the &glos-value;s space, so they are available
+to the &tag-value; tag on subsequent requests.
+FormIgnore stops propagation.
+-->
1.3 +135 -0 xmldocs/glossary/session
rev 1.3, prev_rev 1.2
Index: session
===================================================================
RCS file: /var/cvs/xmldocs/glossary/session,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- session 15 Dec 2004 14:24:00 -0000 1.2
+++ session 11 Jun 2005 17:22:36 -0000 1.3
@@ -0,0 +1,135 @@
+=item Session parameters
+
+Things like where the user originally found your catalog ([data session source]
+and [data session referer]), domain they are from ([data session host]),
+the time of their last access ([data session time]), and many other parameters.
+
+
+
+
+=head2 A typical user session for an e-commerce system
+
+The user hears about your site via a search engine, link from another
+page, or click-thru from a banner ad. They access the link, which is a
+URL pointing to the Interchange link program (called VLINK or TLINK, more
+on that below). The Interchange server is already running on your system,
+and your site has been designed and tested.
+
+The link program, which is a regular CGI program, calls the Interchange
+server. The Interchange server sees the path information which is appended
+to the URL calling it, and brings up the corresponding page. The page
+contains a link to order items from your catalog.
+
+The user clicks on the link and Interchange looks in the a products database,
+finds the item, and places it in the user's shopping cart. (Each user has
+a separate shopping cart, which is attached to their session.)
+
+Once the user decides to purchase, they check out by filling out a form
+with their name, address, payment information, etc. In the process they
+may make choices about how the product should be shipped, how they will
+pay, and provide any other information you may ask for. They then place
+(or "submit") the order.
+
+Their payment may be taken at that point via real-time credit card
+approval and a soft-goods product downloaded -- or their order
+information may be simply sent to you, the store owner, via encrypted
+email. The order is saved to a database table (and a file as backup),
+or in the case of fully-automated systems sent directly to an order
+entry program or database link.
+
+All of these operations are fully configurable by you. The base Interchange
+distribution includes a sample store -- some users have simply customized
+the text and images inside, changed the database entries, and opened
+their store. You will probably want to fully customize for a distinctive
+catalog look and feel.
+
+=head2 How Interchange Manages Sessions
+
+Normally, each request for a World Wide Web page which comes in to a
+server stands on its own. While the server will probably know which
+machine a request comes from, it may not know if the next request
+comes from the same browser or even from the same user on that
+machine.
+
+Interchange keeps track of who is ordering what by including in the URL
+a session id, which is a random piece of text which is different for
+each customer browsing the catalog.
+
+This session ID is either tracked with cookies, or it can be passed
+along through special URLs within pages. Pages
+served by Interchange can generate a special URL
+for every link. Here is an example of such a URL:
+
+ http://machine.company.com/cgi-bin/standard/browse?id=WehUkATn&mv_pc=1
+
+An explanation of each part:
+
+=over 4
+
+=item machine.company.com
+
+Internet address of the server hosting the Interchange site.
+
+=item cgi-bin
+
+Informs server that the requested page will be generated by a
+program.
+
+=item standard
+
+Name of the program to run
+
+=item browse
+
+Page of the catalog to display
+
+=item id=WehUkATn
+
+The session ID
+
+=item mv_pc=1
+
+A unique integer (or source code, if it contains a letter) which prevents
+browsers from caching the URL.
+
+=head2 Page Delivery
+
+Interchange pages are written in regular HTML with extensions.
+Interchange extensions look like:
+
+ <a href="[area specials]">See our specials!</a>
+
+Pages are delivered through the following steps:
+
+=over 4
+
+=item *
+
+The HTTP server (like Apache) receives a request for a Interchange page.
+
+=item *
+
+The server is already running as a daemon, and the request calls a small
+C program (source is vlink.c or tlink.c) that is I<named according to
+which catalog is being called.> This program communicates with the
+Interchange program via a UNIX- or INET-domain socket.
+
+NOTE: Interchange can also link via other means such as C<mod_interchange>.
+
+=item *
+
+Interchange reads the source page from the Interchange pages directory, and
+interprets the Interchange tags in the file. If the page doesn't exist,
+and corresponds to a part number in the database, it is built "on the
+fly" using a template page. In the process, it may read or modify any
+number of database tables. If the user's browser doesn't accept cookies,
+then any links generated on the page will contain the I<session ID>, which
+is needed to ensure the user's session is retained.
+
+=item *
+
+The page, which is now entirely in regular HTML, is delivered to
+the HTTP server, which returns it to the browser.
+
+=back
+
1.2 +24 -8 xmldocs/refs/EncryptProgram
rev 1.2, prev_rev 1.1
Index: EncryptProgram
===================================================================
RCS file: /var/cvs/xmldocs/refs/EncryptProgram,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- EncryptProgram 19 Feb 2005 17:14:03 -0000 1.1
+++ EncryptProgram 11 Jun 2005 17:22:36 -0000 1.2
@@ -4,29 +4,45 @@
__NAME__ synopsis
-<group choice='req'>
<arg choice='plain'><replaceable>filename</replaceable></arg>
-</group>
+ <arg choice='opt'><replaceable>arguments</replaceable></arg>
__END__
__NAME__ description
-Specify default encryption program. It will be called to perform tasks such
-as encrypting credit card numbers (<emphasis role='bold'>if</emphasis> they
-are stored on the server).
+Specify default encryption program, and a template to call it. The encryption
+program will be called to perform tasks such as encrypting credit card
+numbers (<emphasis role='bold'>if</emphasis> they are stored on the server).
+</para><para>
+Two placeholders can be used, <literal>%p</literal> and
+<literal>%f</literal>. At encryption time, the former expands to a password,
+the latter one to a temporary file name.
</para><para>
If &IC; can found a variant of <command>gpg</command>/<command>pgp</command>
on your system, it is the default. Setting of <literal>none</literal> disables
encryption.
__END__
+
+__NAME__ notes
+This directive is different from &conf-PGP;, which is used to encrypt
+<emphasis>complete</emphasis> orders and not just part of their contents.
+</para><para>
+If the order &conf-Route; method of sending orders is used (default in the
+&std-catalog; demo), then this directive sets the default value of
+the <literal>encrypt_program</literal> attribute.
+__END__
+
__NAME__ see also
-DEBUG, DataTrace, DebugFile
+DEBUG, DataTrace, DebugFile,PGP
__END__
-__NAME__ example: Enabling DumpStructure
+__NAME__ example: Specifying EncryptProgram
<programlisting>
-DumpStructure Yes
+EncryptProgram /usr/local/bin/gpg -feat sales at company.com
</programlisting>
__END__
+__NAME__ missing
+PORT_OLD
+__END__
1.1 xmldocs/refs/Filter
rev 1.1, prev_rev 1.0
Index: Filter
===================================================================
__NAME__ purpose
specify variables and filters through which they should be run through automatically
__END__
__NAME__ see also
filter
__END__
__NAME__ synopsis
<group choice='req'>
<arg choice='plain'>
<replaceable>variable_name</replaceable>
<replaceable>filter_name</replaceable>
</arg>
</group>
__END__
__NAME__ description
The directive assigns one or more filters (comma separated) that should be
automatically applied to a variable.
__END__
__NAME__ example: Automatically filtering "mail_lists" variable
Some variables submitted by the user come back null-separated, such as
values from multi-select boxes where the selected items are separated
by null (<literal>\0</literal>) characters. To automatically change those
nulls to spaces, you could use this directive:
<programlisting><![CDATA[
Filter mail_lists null_to_space
]]></programlisting>
__END__
__NAME__ notes
You could also use the &tag-filter; tag to help yourself, but in the long
run the &conf-Filter; approach reduces typing and minimizes the chance
of omission.
__END__
1.1 xmldocs/refs/FormIgnore
rev 1.1, prev_rev 1.0
Index: FormIgnore
===================================================================
__NAME__ purpose
specify variables that should not be propagated from the CGI to Values space
__END__
__NAME__ see also
__END__
__NAME__ synopsis
<group choice='req'>
<arg choice='plain' rep='repeat'>
<replaceable>variable_name</replaceable>
</arg>
</group>
__END__
__NAME__ description
The directive specifies variables that should not be propagated from the
&glos-CGI; into &glos-value;s space.
__END__
__NAME__ example: Defining FormIgnore
<programlisting><![CDATA[
FormIgnore mv_searchtype
]]></programlisting>
__END__
__NAME__ notes
See &glos-CGI; glossary entry for introduction and discussion.
__END__
__NAME__ missing
PORT_OLD
__END__
1.1 xmldocs/refs/FractionalItems
rev 1.1, prev_rev 1.0
Index: FractionalItems
===================================================================
__NAME__ purpose
allow fractional quantities in the shopping cart
__END__
__NAME__ synopsis
<group choice='req'>
<arg choice='plain'>0</arg>
<arg choice='plain'>1</arg>
</group>
__END__
__NAME__ description
The directive specifies whether
the quantity of items in the shopping cart could be fractional,
such as <literal>2.5</literal> or <literal>1.25</literal>.
__END__
__NAME__ notes
__END__
__NAME__ see also
__END__
__NAME__ example: Enabling FractionalItems
<programlisting>
FractionalItems 1
</programlisting>
__END__
1.1 xmldocs/refs/History
rev 1.1, prev_rev 1.0
Index: History
===================================================================
__NAME__ purpose
how many most-recent user clicks should be saved in session history
__END__
__NAME__ synopsis
<group choice='req'>
<arg choice='plain'><replaceable>count</replaceable></arg>
</group>
__END__
__NAME__ description
The directive specifies
how many of the most recent user clicks should be stored in the session history.
__END__
__NAME__ see also
__END__
__NAME__ example: Defining History
<programlisting>
History 10
</programlisting>
__END__
More information about the docs
mailing list