[docs] xmldocs - docelic modified 10 files
docs at icdevgroup.org
docs at icdevgroup.org
Wed Dec 14 18:11:00 EST 2005
User: docelic
Date: 2005-12-14 23:10:59 GMT
Modified: . Makefile TODO
Modified: bin coup
Modified: glossary array
Modified: guides programming-style.xml
Modified: refs ConfigDir
Added: refs CartTrigger CartTriggerQuantity ConfigDatabase
Removed: glossary balloon
Log:
- Makefile: turn orderchecks back on (the error that prevented them from
working was fixed in some earlier commit - it was the docbook/olink*.nc
files)
- TODO: item
- bin/coup: add simple debugging support
- refs/*: three new items documented (thanks Jon & Ethan Rowe for a CVS commit
with good description)
- glossary/*: remove 1 unneeded, document 1
Revision Changes Path
1.80 +2 -2 xmldocs/Makefile
rev 1.80, prev_rev 1.79
Index: Makefile
===================================================================
RCS file: /var/cvs/xmldocs/Makefile,v
retrieving revision 1.79
retrieving revision 1.80
diff -u -r1.79 -r1.80
--- Makefile 6 Dec 2005 21:54:39 -0000 1.79
+++ Makefile 14 Dec 2005 23:10:59 -0000 1.80
@@ -12,7 +12,7 @@
#############################################################
# Base definitions
-SYMBOL_TYPES= pragmas vars tags confs filters
+SYMBOL_TYPES= pragmas vars tags confs filters orderchecks
GUIDES = iccattut programming-style upgrade faq index optimization search xmldocs
HOWTOS = howtos
GLOSSARY = glossary
@@ -33,7 +33,7 @@
REFS_AUTOGEN_FLAGS ?=
VPATH = guides refs howtos glossary
-#.SILENT:
+.SILENT:
.PHONY: all complete
.PHONY: skel
.PHONY: guides howtos symbols glossary
1.78 +2 -0 xmldocs/TODO
rev 1.78, prev_rev 1.77
Index: TODO
===================================================================
RCS file: /var/cvs/xmldocs/TODO,v
retrieving revision 1.77
retrieving revision 1.78
diff -u -r1.77 -r1.78
--- TODO 19 Nov 2005 12:25:49 -0000 1.77
+++ TODO 14 Dec 2005 23:10:59 -0000 1.78
@@ -162,3 +162,5 @@
- missing </p>s
- lowercase SELECTED/CHECKED ?
+
+Check CartTrigger[Quantity]
1.4 +3 -0 xmldocs/bin/coup
rev 1.4, prev_rev 1.3
Index: coup
===================================================================
RCS file: /var/cvs/xmldocs/bin/coup,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- coup 30 Sep 2004 09:39:09 -0000 1.3
+++ coup 14 Dec 2005 23:10:59 -0000 1.4
@@ -9,6 +9,7 @@
use strict;
use Fatal qw/chdir/;
use Getopt::Long;
+use constant DEBUG => 0;
my $home = $ENV{PWD};
my $update = 0;
@@ -33,12 +34,14 @@
if ( $update ) {
chdir $_;
print STDERR "CUP $rev\n";
+ DEBUG and print "DBG $ENV{PWD}: cvs -z9 update >& ../../tmp/cup.$rev\n";
system("cvs -z9 update >& ../../tmp/cup.$rev");
}
}
else { # Need to perform checkout
chdir "sources";
print STDERR "CO $rev\n";
+ DEBUG and print "DBG $ENV{PWD}: cvs -z9 -d:pserver:cvs\@cvs.icdevgroup.org:/var/cvs checkout -d $rev $cvs_r interchange >& ../tmp/co.$rev";
system("cvs -z9 -d:pserver:cvs\@cvs.icdevgroup.org:/var/cvs checkout -d $rev $cvs_r interchange >& ../tmp/co.$rev");
}
1.3 +6 -0 xmldocs/glossary/array
rev 1.3, prev_rev 1.2
Index: array
===================================================================
RCS file: /var/cvs/xmldocs/glossary/array,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- array 15 Dec 2004 14:24:00 -0000 1.2
+++ array 14 Dec 2005 23:10:59 -0000 1.3
@@ -0,0 +1,6 @@
+In general terms, "array" can be considered a synonym for "list". It
+implies a list of elements.
+</para><para>
+In the &PERL; programming language, "list" refers to an unnamed list of any
+kind, while "array" refers to a practical, named &PERL; variable of list
+type.
1.6 +1 -1 xmldocs/guides/programming-style.xml
rev 1.6, prev_rev 1.5
Index: programming-style.xml
===================================================================
RCS file: /var/cvs/xmldocs/guides/programming-style.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- programming-style.xml 29 Aug 2005 19:19:12 -0000 1.5
+++ programming-style.xml 14 Dec 2005 23:10:59 -0000 1.6
@@ -219,7 +219,7 @@
<itemizedlist>
<listitem><para>
Do not use the hash character <literal>#</literal> in weird contexts.
- Use it only for comments (putting a space between eventual inline code and
+ Use it only for comments (putting a space between eventual code and inline
comment) or simple substitution such as <literal>s#A#B#g</literal>.
(Impact: cosmetic)
<programlisting><![CDATA[
1.3 +1 -1 xmldocs/refs/ConfigDir
rev 1.3, prev_rev 1.2
Index: ConfigDir
===================================================================
RCS file: /var/cvs/xmldocs/refs/ConfigDir,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ConfigDir 21 May 2005 12:51:29 -0000 1.2
+++ ConfigDir 14 Dec 2005 23:10:59 -0000 1.3
@@ -5,7 +5,7 @@
__NAME__ synopsis
<group choice='req'>
- <arg choice='plain'>directory</arg>
+ <arg choice='plain'><replaceable>directory_name</replaceable></arg>
</group>
__END__
1.1 xmldocs/refs/CartTrigger
rev 1.1, prev_rev 1.0
Index: CartTrigger
===================================================================
__NAME__ purpose
specify subroutines to invoke when users' electronic cart contents change
__END__
__NAME__ missing
__END__
__NAME__ see also
CartTriggerQuantity
__END__
__NAME__ synopsis
<group choice='req'>
<arg choice='plain' rep='repeat'><replaceable>subroutine_name</replaceable></arg>
</group>
__END__
__NAME__ description
The directive specifies names of the &PERL; subroutines to be invoked
when users' electronic &glos-cart; contents change. The subroutines can
be defined on both global and catalog level.
</para><para>
The subroutines execute whenever the contents of users' cart are changed via
the standard means available through &glos-CGI; variable space (i.e. when
changes are invoked via the &tag-process; system &glos-actionmap; —
through <mv>mv_order_item</mv> and <mv>mv_order_quantity</mv> field submissions,
or from a standard Interchange cart page).
</para><para>
The subroutines will be executed per-change, such that any page process
resulting in multiple alterations to the cart will potentially call these
functions multiple times.
</para><para>
The following arguments are passed to all specified subroutines:
<itemizedlist>
<listitem><para>
A reference to the user's cart
</para></listitem>
<listitem><para>
A scalar representing the action that fired the trigger; its value will be
one of <literal>add</literal>, <literal>update</literal> or
<literal>delete</literal>
</para></listitem>
<listitem><para>
A hashref pointing to the new row (except for the <literal>delete</literal>
action, in which case this will be undefined)
</para></listitem>
<listitem><para>
A hashref representing the old row (except for the <literal>add</literal>
action); for the <literal>update</literal> action, this will be a
<emphasis role='bold'>copy</emphasis> of the row prior to the change.
The old row will no longer be a member of the cart
</para></listitem>
<listitem><para>
The cart symbolic name
</para></listitem>
</itemizedlist>
</para><para>
The return value from each subroutine call is pushed onto an array;
when the particular trigger firing is complete (i.e. all subroutines specified
in &conf-CartTrigger; have been called), the full array of results will be
returned. However, the initial version of this functionality does not use
these return values in any meaningful way.
__END__
__NAME__ notes
It must be noted that the &IC; cart subsystem is based on arrayrefs of hashrefs
(all &PERL; programming terms) — there is no object encapsulation for
limiting or monitoring program access to the contents of any cart.
Consequently, direct manipulation of the cart from within &PERL;
<emphasis role='bold'>will not</emphasis> cause these triggers to fire. The
triggers only fire when the cart contents are modified through the standard
Interchange &glos-CGI;-based variable processing. Therefore, it is assumed
(for the moment, at least) that any programmer sufficiently comfortable or
confident to manipulate cart contents directly can also be given the
responsibility of deciding whether or not it is appropriate to invoke cart
triggers along the way.
__END__
__NAME__ example: Specifying CartTrigger
<programlisting>
CartTrigger cart_update1 cart_update2
</programlisting>
__END__
1.1 xmldocs/refs/CartTriggerQuantity
rev 1.1, prev_rev 1.0
Index: CartTriggerQuantity
===================================================================
__NAME__ purpose
specify whether quantity changes to existing electronic cart items will cause CartTrigger subroutines to execute
__END__
__NAME__ see also
CartTrigger
__END__
__NAME__ synopsis
<group choice='req'>
<arg choice='plain'>0</arg>
<arg choice='plain'>1</arg>
</group>
__END__
__NAME__ description
The directive specifies whether quantity changes on existing electronic cart
items will cause specified &conf-CartTrigger; subroutines to execute.
</para><para>
Note, however, that a quantity change to zero will result in item deletion,
and will consequently cause &conf-CartTrigger;s to execute regardless
of &conf-CartTriggerQuantity;'s value.
__END__
__NAME__ notes
It must be noted that the &IC; cart subsystem is based on arrayrefs of hashrefs
(all &PERL; programming terms) — there is no object encapsulation for
limiting or monitoring program access to the contents of any cart.
Consequently, direct manipulation of the cart from within &PERL;
<emphasis role='bold'>will not</emphasis> cause these triggers to fire. The
triggers only fire when the cart contents are modified through the standard
Interchange &glos-CGI;-based variable processing. Therefore, it is assumed
(for the moment, at least) that any programmer sufficiently comfortable or
confident to manipulate cart contents directly can also be given the
responsibility of deciding whether or not it is appropriate to invoke cart
triggers along the way.
__END__
__NAME__ example: Setting CartTriggerQuantity
<programlisting>
CartTriggerQuantity yes
</programlisting>
__END__
1.1 xmldocs/refs/ConfigDatabase
rev 1.1, prev_rev 1.0
Index: ConfigDatabase
===================================================================
__NAME__ purpose
specify database which should hold definitions usually found in catalog.cfg
__END__
__NAME__ synopsis
<arg choice='plain'><replaceable>name</replaceable></arg>
<arg choice='plain'><replaceable>source_file</replaceable></arg>
<arg choice='plain'><replaceable>type</replaceable></arg>
__END__
__NAME__ description
The directive allows one to keep the usual &ccf; definitions in a
&glos-database; table.
</para><para>
By using the special option <literal>LOAD</literal>, it is also possible to
instruct &IC; to fill the &glos-database; with initial data found in your
&ccf; — just make sure to remove that option on subsequent restarts.
__END__
__NAME__ notes
Even though this appears to be both global and catalog &glos-configuration;
directive, it is only implemented on &glos-catalog; level.
__END__
__NAME__ example: Defining ConfigDatabase
You first need to create the table in an &glos-SQL; database
that you will use to store config directives. Here's the SQL code needed:
<programlisting>
create table config (
code varchar(32) NOT NULL PRIMARY KEY,
directive varchar(64) NOT NULL,
value varchar(255),
extended text
);
</programlisting>
Just for the record, once you have the above database table,
sample database contents of:
<programlisting>
code|directive|value|extended
C0001|VariableDatabase|variable
C0002|SessionExpire|2 hours|
C0003|Variable|foo| bar
</programlisting>
will correspond to the usual &ccf; definitions:
<programlisting>
VariableDatabase variable
SessionExpire 2 hours
Variable foo <<EOF
bar
EOF
</programlisting>
__END__
__NAME__ example: Automatically populating ConfigDatabase with initial data from catalog.cfg
<programlisting>
ConfigDatabase config config.txt dbi:mysql:config
ConfigDatabase config LOAD 1
</programlisting>
__END__
__NAME__ author
__mheins__
__END__
More information about the docs
mailing list