Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

- 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
  • Loading branch information...
commit 34d199bd21bc4f22b11347cda41277c25b6381f6 1 parent 043a47a
@docelic docelic authored
View
4 Makefile
@@ -12,7 +12,7 @@ IC_VERSIONS = 4.6.0 4.8.0 5.0.0 5.2.0 cvs-head
#############################################################
# 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 = bin/refs-autogen
REFS_AUTOGEN_FLAGS ?=
VPATH = guides refs howtos glossary
-#.SILENT:
+.SILENT:
.PHONY: all complete
.PHONY: skel
.PHONY: guides howtos symbols glossary
View
2  TODO
@@ -162,3 +162,5 @@ In IC source:
- missing </p>s
- lowercase SELECTED/CHECKED ?
+
+Check CartTrigger[Quantity]
View
3  bin/coup
@@ -9,6 +9,7 @@ use warnings;
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 ( -d ($_ = "sources/$rev") ) { # Source is here, only update
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");
}
View
6 glossary/array
@@ -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.
View
0  glossary/balloon
No changes.
View
2  guides/programming-style.xml
@@ -219,7 +219,7 @@ Entering and tracking all bugs, even those you find and then fix yourself,
<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[
View
87 refs/CartTrigger
@@ -0,0 +1,87 @@
+__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; &mdash;
+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) &mdash; 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__
+
View
46 refs/CartTriggerQuantity
@@ -0,0 +1,46 @@
+__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) &mdash; 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__
+
View
65 refs/ConfigDatabase
@@ -0,0 +1,65 @@
+__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; &mdash; 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 &lt;&lt;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__
View
2  refs/ConfigDir
@@ -5,7 +5,7 @@ __END__
__NAME__ synopsis
<group choice='req'>
- <arg choice='plain'>directory</arg>
+ <arg choice='plain'><replaceable>directory_name</replaceable></arg>
</group>
__END__
Please sign in to comment.
Something went wrong with that request. Please try again.