[docs] docs - jon modified 11 files
docs@interchange.redhat.com
docs@interchange.redhat.com
Fri Apr 12 18:57:00 2002
User: jon
Date: 2002-04-12 22:53:19 GMT
Modified: . ic_ecommerce.sdf ic_howto_cvs.sdf icadvanced.sdf
Modified: iccattut.sdf icconfig.sdf icdatabase.sdf icfaq.sdf
Modified: icfoundation.sdf ictags.sdf ictemplates.sdf
Modified: icupgrade.sdf
Log:
Picking nits.
Went through some docs with ispell, updated copyright dates, etc.
Revision Changes Path
1.11 +10 -10 docs/ic_ecommerce.sdf
rev 1.11, prev_rev 1.10
Index: ic_ecommerce.sdf
===================================================================
RCS file: /var/cvs/docs/ic_ecommerce.sdf,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -u -r1.10 -r1.11
--- ic_ecommerce.sdf 6 Dec 2001 03:27:27 -0000 1.10
+++ ic_ecommerce.sdf 12 Apr 2002 22:53:18 -0000 1.11
@@ -1,10 +1,10 @@
!init OPT_LOOK="akopia"; OPT_STYLE="manual"
-# $Id: ic_ecommerce.sdf,v 1.10 2001/12/06 03:27:27 jon Exp $
+# $Id: ic_ecommerce.sdf,v 1.11 2002/04/12 22:53:18 jon Exp $
!define DOC_NAME "Interchange Ecommerce Functions"
!define DOC_TYPE ""
!define DOC_CODE "ic_ecommerce"
-!define DOC_VERSION substr('$Revision: 1.10 $',11, -2)
+!define DOC_VERSION substr('$Revision: 1.11 $',11, -2)
!define DOC_STATUS "Draft"
!define DOC_PROJECT "Interchange"
!define DOC_URL "http://interchange.redhat.com/doc/ic_ecommerce.html"
@@ -54,7 +54,7 @@
named attributes:
> [order code="sku" quantity="n"* href="page"* cart="cartname"* base="table"*]
-> * = optional paramenters
+> * = optional parameters
Expands into a hypertext link which will include the specified
code in the list of products to order and display the order page. B<code>
@@ -83,7 +83,7 @@
=item [/order]
Expands into </a>. Used with the order element, such as: Buy a
-C<[order TK112]>ToasterC<[/order]> today.
+C<[order TK112]>Toaster<[/order]> today.
=back
@@ -196,7 +196,7 @@
The form parameter value C<mv_order_fly> can contain any number of fields
which will set corresponding parameters in the item attributes. The fields
-are separated by the pipe (C<|>) character and contain value-parmeter
+are separated by the pipe (C<|>) character and contain value-parameter
pairs separated by an = sign. (These are URL-encoded by the C<[area ...]> or
C<[page ...]> tag, of course.) You can set a size, color, or any other parameter.
@@ -504,7 +504,7 @@
=item 4
-If PriceBreaks is in use, it's price will take precedence over the
+If PriceBreaks is in use, its price will take precedence over the
value of C<CommonAdjust>, though it may also contain a CommonAdjust string.
=item 5
@@ -619,7 +619,7 @@
> $Vend::Interpolate::item->{size} gives size for current item (if there)
> $Vend::Interpolate::item->{mv_ib} gives database ordered from
-=item [valid minivend tags]
+=item [valid Interchange tags]
If the settor begins with a square bracket (C<[>) or underscore, it
is parsed for Interchange tags with variable substitution (but no Locale
@@ -787,7 +787,7 @@
Numbers that begin with an equals sign (C<=>) are used as absolute
prices and are I<interpolated for Interchange tags first>, so you can
-use subroutines to set the price. To facilite coordination with the
+use subroutines to set the price. To facilitate coordination with the
subroutine, the session variables C<item_code> and C<item_quantity> are
set to the code and quantity of the item being evaluated. They would
be accessed in a global subroutine with C<$Vend::Session->>C<{item_code}>
@@ -1002,7 +1002,7 @@
> 1. A discount for one particular item code (key is the item-code)
> 2. A discount applying to all item codes (key is ALL_ITEMS)
-> 3. A discount for an individual line item (set the mv_disount attribute
+> 3. A discount for an individual line item (set the mv_discount attribute
> with embedded Perl)
> 4. A discount applied after all items are totaled
> (key is ENTIRE_ORDER)
@@ -1525,7 +1525,7 @@
Line:
-N:Copyright 2001 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
+N:Copyright 2001-2002 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
1.9 +67 -68 docs/ic_howto_cvs.sdf
rev 1.9, prev_rev 1.8
Index: ic_howto_cvs.sdf
===================================================================
RCS file: /var/cvs/docs/ic_howto_cvs.sdf,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -u -r1.8 -r1.9
--- ic_howto_cvs.sdf 1 Apr 2002 21:26:46 -0000 1.8
+++ ic_howto_cvs.sdf 12 Apr 2002 22:53:18 -0000 1.9
@@ -1,10 +1,10 @@
!init OPT_LOOK="akopia"; OPT_STYLE="manual"
-# $Id: ic_howto_cvs.sdf,v 1.8 2002/04/01 21:26:46 kwalsh Exp $
+# $Id: ic_howto_cvs.sdf,v 1.9 2002/04/12 22:53:18 jon Exp $
!define DOC_NAME "Interchange + CVS HOWTO"
!define DOC_TYPE ""
!define DOC_CODE "ic_howto_cvs"
-!define DOC_VERSION substr('$Revision: 1.8 $', 11, -2)
+!define DOC_VERSION substr('$Revision: 1.9 $', 11, -2)
!define DOC_STATUS "Draft"
!define DOC_PROJECT "Interchange"
!define DOC_URL "http://interchange.redhat.com/doc/ic_howto_cvs.html"
@@ -25,11 +25,11 @@
N:I intend for this document to be useful to those who are not yet familiar with CVS as well as those who are. If you already know how to setup a pserver then you might just skim chapter 2 ("Setup CVS"), or skip it all together.
-N:In addition, I have tried to write at a technical level that would be on par with what I percieve to be the average Interchange user that participates on the interchange-users mailing list. It is assumed that the reader can and already has setup Interchange and the template catalog (such as foundation or construct) is working correctly.
+N:In addition, I have tried to write at a technical level that would be on par with what I perceive to be the average Interchange user that participates on the interchange-users mailing list. It is assumed that the reader can and already has setup Interchange and the template catalog (such as foundation or construct) is working correctly.
H2:Contact the author
-N:If you find any spelling errors, technical slipups, mistakes, subliminal messages, or if you wish to send feedback, critique, remarks, comments, or if you wish to contribute examples, instructions for alternative platforms, chapters, or other material, please do so.
+N:If you find any spelling errors, technical slip-ups, mistakes, subliminal messages, or if you wish to send feedback, critique, remarks, comments, or if you wish to contribute examples, instructions for alternative platforms, chapters, or other material, please do so.
N:The preferred method of submitting changes is in the form of a context diff against the SDF source file (ic_cvs.sdf). Please address your correspondence to:
@@ -41,7 +41,7 @@
*What is CVS all about?
-*What are it's advantages?
+*What are its advantages?
N:The official CVS website ({{URL:http://www.cvshome.org/new_users.html}}) has more detailed answers to these questions, but here are some brief points of interest.
@@ -51,13 +51,13 @@
*Branching releases. Concurrently develop an unstable development version as well as fix bugs in the stable production version.
-*Multiple developers can work on the same catalog and even the same file at the same time. (For more information about how multiple simultaneous writes are merged and conflicts resolved, see the cvs docs in the {{SECT:Resources}} Appendix).
+*Multiple developers can work on the same catalog and even the same file at the same time. (For more information about how multiple simultaneous writes are merged and conflicts resolved, see the CVS docs in the {{SECT:Resources}} Appendix).
*CVS is better than ftp for file transfer, because it automatically downloads only changed files, and even then, only the portion of the file that has changed (using patches).
*CVS can automatically merge two simultaneous writes to the same file by different developers.
-*Allows one to keep track of the changes that have been made over time (many release managers repackage cvs commit logs into WHATSNEW, HISTORY, and/or NEWS files).
+*Allows one to keep track of the changes that have been made over time (many release managers repackage CVS commit logs into WHATSNEW, HISTORY, and/or NEWS files).
H2:How to use this document
@@ -66,17 +66,17 @@
N:Simple
*One server
*One catalog
- *One cvs module
+ *One CVS module
*One branch
N:Medium
*One server
*Two catalogs (e.g., one is live, one is development)
- *One cvs modules
- *Seperate development and live branches
+ *Two CVS modules
+ *Separate development and live branches
N:Complex/Custom
*Multiple servers (e.g., developers' servers, staging servers, and live servers)
*Multiple catalogs
- *Multiple cvs modules
+ *Multiple CVS modules
*Multiple branches
*Custom setup
@@ -87,18 +87,18 @@
H2:Assumptions
N:Here are some of the assumptions that I make that apply to various parts of the rest of this document:
-*Red Hat 7.x
+*Red Hat Linux 7.x
*Interchange installed (RPM or tarball)
-*Default interchange tarball installation directory paths (adjust for your environment)
+*Default Interchange tarball installation directory paths (adjust for your environment)
*Template catalog setup and working
Note:I will assume "foundation" for the catalog name and directory paths, but it should be just as easy to use this document with the construct catalog or your own catalog by mentally transposing the names and paths.
-N:There shouldn't be any reason why you could not do everything I mention here on other Linux distributions, unicies or Windows (using cygwin). However, my statements will reflect Red Hat 7.x. Additionally, Red Hat 6.x is for the most part the same as 7.x, except for the difference of using inetd instead of xinetd to setup pserver.
+N:There shouldn't be any reason why you could not do everything I mention here on other Linux distributions, Unices or Windows (using cygwin). However, my statements will reflect Red Hat Linux 7.x. Additionally, Red Hat Linux 6.x is for the most part the same as 7.x, except for the difference of using inetd instead of xinetd to setup pserver.
H2:Install CVS
-N:This is the easy part. For Red Hat systems, download the cvs rpms and install them. The following RPM command will download and install the Red Hat 7.1 version of cvs from rpmfind.net.
+N:This is the easy part. For Red Hat Linux systems, download the CVS rpms and install them. The following RPM command will download and install the Red Hat 7.1 version of CVS from rpmfind.net.
Note:You need to be root to complete the following tasks
@@ -107,7 +107,7 @@
rpm -Uvh ftp://speakeasy.rpmfind.net/linux/redhat/7.1/en/os/i386/RedHat/RPMS/cvs-1.11-3.i386.rpm
!endblock
-N:Create the user and group that will administrate the interchange repository. For this document, it will be the interch user, (which was setup during the installation of Interchange). But if you understand the mechanics of Unix users/groups, then you can use whatever username and group scheme you prefer. For example, some create a cvs user and cvs group, then add the interchange user and catalog owner to it's group and/or vise-versa. The integration of interchange and CVS in the latter portion of this document will require that the CVS user has some write capability to the catalog directory.
+N:Create the user and group that will administrate the Interchange repository. For this document, it will be the interch user, (which was setup during the installation of Interchange). But if you understand the mechanics of Unix users/groups, then you can use whatever username and group scheme you prefer. For example, some create a cvs user and cvs group, then add the Interchange user and catalog owner to its group or vice-versa. The integration of Interchange and CVS in the latter portion of this document will require that the CVS user can write to the catalog directory.
H2:Create the CVS repository directory
@@ -152,11 +152,11 @@
*{{URL:http://freshmeat.net/projects/cvsadmin/}}
*{{URL:http://freshmeat.net/projects/cvspadm/}}
-N:I recommend cvsadmin, but there are also a variety of manual methods that can be used in the absence of such tools, one of which involves copying the system shadow file and modifying it for use by CVS. For more information on this manual method, see the RedHat CVS pserver setup guide by Michael Amorose ({{URL:http://www.michael-amorose.com/cvs/}}).
+N:I recommend cvsadmin, but there are also a variety of manual methods that can be used in the absence of such tools, one of which involves copying the system shadow file and modifying it for use by CVS. For more information on this manual method, see the Red Hat CVS pserver setup guide by Michael Amorose ({{URL:http://www.michael-amorose.com/cvs/}}).
H3:Setup authentication using the cvsadmin tool
-N:You can find a tarball to install on your system using the above address, but here is the address of a recent RPM package of the version. This package is intended for mandrake systems, but is compatible with Red Hat 7.1:
+N:You can find a tarball to install on your system using the above address, but here is the address of a recent RPM package of the version. This package is intended for Mandrake systems, but is compatible with Red Hat Linux 7.1:
*{{URL:ftp://speakeasy.rpmfind.net/linux/Mandrake-devel/contrib/RPMS/cvsadmin-1.0.1-1mdk.i586.rpm}}
@@ -170,7 +170,7 @@
H3:Add your project to the {{F:modules}} configuration file
-N:The format of the modules file is explained in detail in the cvs documentation, here is the simplest way to use it:
+N:The format of the modules file is explained in detail in the CVS documentation, here is the simplest way to use it:
!block example;
{{B:/rep/CVSROOT/modules:}}
@@ -222,7 +222,7 @@
H2:Testing your repository
-N:At this point, you should have a working (though empty) CVS repository. Before we continue with setting up the pserver or importing source code, try logging in as one of the cvs users listed in your CVSROOT/passwd and test the checkout.
+N:At this point, you should have a working (though empty) CVS repository. Before we continue with setting up the pserver or importing source code, try logging in as one of the CVS users listed in your CVSROOT/passwd and test the checkout.
!block example;
#test checkout in home directory of any cvs user
@@ -235,11 +235,11 @@
H2:Setup the CVS pserver
-N:You will likely need to be root to do this, and there are lots of guides on the internet for setting up a cvs pserver, hopefully you wont have any trouble doing it on your particular operating system. See the {{SECT:Resources}} Appendix for more information.
+N:You will likely need to be root to do this, and there are lots of guides on the Internet for setting up a CVS pserver, hopefully you wont have any trouble doing it on your particular operating system. See the {{SECT:Resources}} Appendix for more information.
-H3:Setup pserver in Red Hat 7.1 using xinetd.
+H3:Setup pserver in Red Hat Linux 7.1 using xinetd.
-N:For Red Hat 7.x, edit {{F:/etc/xinetd.d/cvspserver}} (create a new one if none exists). The following works for me, but customization may be required for your environment (see the next section below for an inetd-based system example). This also must be done as root.
+N:For Red Hat Linux 7.x, edit {{F:/etc/xinetd.d/cvspserver}} (create a new one if none exists). The following works for me, but customization may be required for your environment (see the next section below for an inetd-based system example). This also must be done as root.
!block example;
su - root
@@ -273,7 +273,7 @@
H3:Setup pserver in inetd-based systems.
-N:I haven't tested this (any takers?), but something like the following needs to be done for inetd-based systems such as Red Hat 6.2. Make sure that the following files are setup accordingly.
+N:For inetd-based systems such as Red Hat Linux 6.2, make sure that the following files are setup accordingly.
!block example;
{{B:/etc/services:}}
@@ -289,7 +289,7 @@
H3:Testing your pserver
-N:At this point, you should be able to use a cvs client to use your pserver and execute all the same commands that you can locally (which we tested before). You may wish to take advantage of a graphical cvs client, which can be particularly helpful in leveling the learning curve.
+N:At this point, you should be able to use a CVS client to use your pserver and execute all the same commands that you can locally (which we tested before). You may wish to take advantage of a graphical CVS client, which can be particularly helpful in leveling the learning curve.
N:See the {{SECT:Resources}} Appendix for links to some graphical CVS tools.
@@ -297,9 +297,9 @@
H2:Configuring your catalog
-N:Eventually, we will import your catalog into the cvs repository, but first we need to do some work with a temporary copy of the catalog so we can get it into shape for importing.
+N:Eventually, we will import your catalog into the CVS repository, but first we need to do some work with a temporary copy of the catalog so we can get it into shape for importing.
-Note:From here on, assume the use of the interchange user, such as {{EX:interch}}, unless otherwise noted.
+Note:From here on, assume the use of the Interchange user, such as {{EX:interch}}, unless otherwise noted.
E:su - interch
@@ -319,13 +319,13 @@
!block example;
-#Become interchange catalog user
+#Become Interchange catalog user
su - interch
#backup catalog folder first
tar czf ~/foundation_backup.tgz /var/lib/interchange/foundation
-#get rid of any old CVS folders -- (BE CAREFULL!)
+#get rid of any old CVS folders -- (BE CAREFUL!)
cd /var/lib/interchange/foundation
find . -name CVS -exec rm -Rf {} \;
!endblock
@@ -347,7 +347,7 @@
*Will the file be modified by another source?
-N:For example, {{EX:/etc/order.number}} is modified by interchange when run. But not everyone will use a local development model that includes running interchange on a directly checked-out copy of their source. Which means this specific issue is avoided if you upload every edit before viewing your changes on a server.
+N:For example, {{EX:/etc/order.number}} is modified by Interchange when run. But not everyone will use a local development model that includes running Interchange on a directly checked-out copy of their source. Which means this specific issue is avoided if you upload every edit before viewing your changes on a server.
*The likelihood that you will modify the file.
@@ -355,11 +355,11 @@
*Speed.
-N:Managing less files in the repository takes away from the amount of time required for cvs checkout, update, branching, and other cvs actions. For most, this amount of time is small already, but it is a consideration for some.
+N:Managing less files in the repository takes away from the amount of time required for CVS checkout, update, branching, and other CVS actions. For most, this amount of time is small already, but it is a consideration for some.
*Ease of use.
-N:Ease of use is one reason not to remove anything from your catalog before importing it, because it creates the ability to have a completely working catalog from just one checkout (much like the CVS tree at interchange.redhat.com). Whereas if you leave out other directories like etc/ session/ orders/, etc., then you must first combine your checkout with the other working parts of a catalog before the catalog is viable. But this is slower and will bring up lots of harmless notification and warning messages (about changed local versions) if you run interchange on your local source copy (because interchange will touch etc/ session/ orders/, etc. directly, and then warn that your local copy has changed from the CVS copy). You may be able to manage some of these notifications and warnings with {{F:CVSROOT/cvsignore}} or {{EX:$CVSIGNORE}}, see the {{SECT:Resources}} appendix for more details.
+N:Ease of use is one reason not to remove anything from your catalog before importing it, because it creates the ability to have a completely working catalog from just one checkout (much like the CVS tree at interchange.redhat.com). Whereas if you leave out other directories like etc/ session/ orders/, etc., then you must first combine your checkout with the other working parts of a catalog before the catalog is viable. But this is slower and will bring up lots of harmless notification and warning messages (about changed local versions) if you run Interchange on your local source copy (because Interchange will touch etc/ session/ orders/, etc. directly, and then warn that your local copy has changed from the CVS copy). You may be able to manage some of these notifications and warnings with {{F:CVSROOT/cvsignore}} or {{EX:$CVSIGNORE}}, see the {{SECT:Resources}} appendix for more details.
#TODO:CVSIGNORE
@@ -386,7 +386,7 @@
N:Import the remaining portion of the catalog using the {{EX:cvs import}} command, with "foundation" as the module name and repository directory name. See the CVS documentation resources mentioned in Appendix {{SECT:Resources}} for more information.
-N:When you run the import command, it will launch $EDITOR (set to {{EX:'vi'}} earlier), and ask for a message to go along with the import action. Whatever you see fit to write (e.g. "starting new cvs module with my foundation catalog...") is fine.
+N:When you run the import command, it will launch $EDITOR (set to {{EX:'vi'}} earlier), and ask for a message to go along with the import action. Whatever you see fit to write (e.g. "starting new CVS module with my foundation catalog...") is fine.
N:This example {{EX:import}} command includes renaming the foundation "working" directory back to "foundation" for the import.
@@ -435,7 +435,7 @@
H3:Add any needed files to checked-out catalog
-#TODO: Empty directories are pruned, so they will need something in them for them to show up with a -P checkout
+Note that empty directories are pruned, so they will need something in them for them to show up with a -P checkout. Often a zero-byte file called '.empty' is used.
N:If you removed any directories during the streamlining step, we must first add those back so that the catalog is usable to Interchange. In this document, we only removed unneeded files and left empty directories.
@@ -465,7 +465,7 @@
ln -s /var/lib/interchange/foundation/images images
!endblock
-N:Now, you should have a working catalog again. To make sure, start up interchange and test the site with your browser.
+N:Now, you should have a working catalog again. To make sure, start up Interchange and test the site with your browser.
H2:Testing manual CVS updates on Interchange catalogs
@@ -488,7 +488,7 @@
N:Your changed version will now be resident in the repository. Again, CVS documentation is in the {{SECT:Resources}} Appendix.
-N:This time, we can allow the changes to take effect on the code being used by interchange to server pages. To do so, one must run a {{EX:cvs update}} on the catalog directory:
+N:This time, we can allow the changes to take effect on the code being used by Interchange to serve pages. To do so, one must run a {{EX:cvs update}} on the catalog directory:
!block example;
cd /var/lib/interchange/foundation
@@ -511,7 +511,7 @@
N:The {{EX:?}} lines in the above example mean that the CVS server has never heard of the listed directories or files (they are in your local source dir but not in the CVS source dir). It is harmless, but sometimes annoying.
-N:The {{EX:M}} means that sthe file has been modified on your local copy, and is out of sync with the remote CVS version (e.g. when Interchange runs it updates {{F:etc/status.foundation}}). Normally this is corrected by uploading your "modified" version to the server, but in this case, the modification was done by Interchange instead of the programmer, and wasn't meant to be committed back to the CVS repository. These types of messages can be handled with {{EX:$CVSIGNORE}} and {{EX:$CVSROOT/CVSROOT/cvsignore}}.
+N:The {{EX:M}} means that the file has been modified on your local copy, and is out of sync with the remote CVS version (e.g. when Interchange runs it updates {{F:etc/status.foundation}}). Normally this is corrected by uploading your "modified" version to the server, but in this case, the modification was done by Interchange instead of the programmer, and wasn't meant to be committed back to the CVS repository. These types of messages can be handled with {{EX:$CVSIGNORE}} and {{EX:$CVSROOT/CVSROOT/cvsignore}}.
#TODO: CVSIGNORE
@@ -527,7 +527,7 @@
^foundation (date; cat; (sleep 1; cd /var/lib/interchange/foundation; cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1
!endblock
-N:The first line tells cvs that for every commit on modules that start with "foundation" (notice the regular expression {{EX:"^foundation"}}), it will run {{EX:cvs update}} on the given catalog directory in the background. It is important that it is executed in a forked shell (notice the {{EX:"&"}}) after {{EX:sleep}}'ing for 1 second, because otherwise you may run into contention issues that can cause file locking problems. The 1 second timing used above works fine for me, but a longer pause may be necessary for slower computers (you'll know if you get errors about "file locked by user"). See the CVS documentation in the {{SECT:Resources}} Appendix for more details.
+N:The first line tells CVS that for every commit on modules that start with "foundation" (notice the regular expression {{EX:"^foundation"}}), it will run {{EX:cvs update}} on the given catalog directory in the background. It is important that it is executed in a forked shell (notice the {{EX:"&"}}) after {{EX:sleep}}'ing for 1 second, because otherwise you may run into contention issues that can cause file locking problems. The 1 second timing used above works fine for me, but a longer pause may be necessary for slower computers (you'll know if you get errors about "file locked by user"). See the CVS documentation in the {{SECT:Resources}} Appendix for more details.
H2:Automatic e-mail on commit
@@ -682,7 +682,7 @@
Variable SQLDB foundation_dev
!endblock
-N:Now you can restart interchange to make your changes take effect.
+N:Now you can restart Interchange to make your changes take effect.
H2:Splitting updates on commit by tag
@@ -715,7 +715,7 @@
- Commit the result
- Update back to the development version (DEV1)
-N:I do the above so often that I have written a TCL script for WinCVS that will automatically perform the above steps. And similar shell scripts can probably be easily written to match your development environment.
+N:I do the above so often that I have written a Tcl script for WinCVS that will automatically perform the above steps. And similar shell scripts can probably be easily written to match your development environment.
N:The above seems to be the easiest way, to me. However, there are other alternatives detailed in the CVS manual in chapter 5, "Branching and merging", that I highly recommend for reading. One method involves specifying the last version that has already been merged into the live branch using a specific version number, date, relative time, or special purpose tag.
@@ -723,21 +723,21 @@
N:This is the productivity tips section, which will hopefully help you to be able to get more done in less time.
-H2:Workstation interchange installation
+H2:Workstation Interchange installation
-N:Not all developers work on Linux workstations, many use Apples (graphics designers and html gurus tend to, I've found), and many use Windows. This means that many developers have the extra step of uploading their changes to a Unix server where Interchange is running in order to see their changes.
+N:Not all developers work on Linux workstations, many use Apples (graphics designers and HTML gurus tend to, I've found), and many use Windows. This means that many developers have the extra step of uploading their changes to a Unix server where Interchange is running in order to see their changes.
-N:The remedy to that is to setup an interchange server on your workstation, or any location that has direct access to the CVS source files. I'll explain:
+N:The remedy to that is to setup an Interchange server on your workstation, or any location that has direct access to the CVS source files. I'll explain:
-N:The interchange server that runs where the CVS server is (that we setup earlier) can be seen as the gathering point for all the developers. However, each developer may run as many interchange daemons as he/she requires in a local context for the purpose of seeing the changes made before uploading them via CVS.
+N:The Interchange server that runs where the CVS server is (that we setup earlier) can be seen as the gathering point for all the developers. However, each developer may run as many Interchange daemons as he/she requires in a local context for the purpose of seeing the changes made before uploading them via CVS.
-N:For example, Bob could setup another interchange catalog on the same server as the CVS, (e.g. foundation-bob). To get direct access to those files (rather than FTP), Bob could use NFS mounts (if Bob's workstation is Linux) or SMB mounts using Samba if his workstation is a Windows variant. Any way that Bob can get direct access to the files will save him some time (by cutting out the "upload" from the "edit->upload->test" development cycle). One could even use Vmware to run a Linux server on your Windows workstation.
+N:For example, Bob could setup another Interchange catalog on the same server as the CVS, (e.g. foundation-bob). To get direct access to those files (rather than FTP), Bob could use NFS mounts (if Bob's workstation is Linux) or SMB mounts using Samba if his workstation is a Windows variant. Any way that Bob can get direct access to the files will save him some time (by cutting out the "upload" from the "edit->upload->test" development cycle). One could even use VMware to run a Linux server on your Windows workstation.
Note: You can now use the cygwin compatibility confirmed in Interchange versions 4.7.6 and above to run Interchange right on your Windows workstation.
N:The result will be that you can modify the files with your favorite text editor and see the results immediately through your local catalog. Setting up the catalog initially is quite easy. Just follow the same steps used to setup the CVS catalog. Which is:
-*Stop interchange.
+*Stop Interchange.
*bin/makecat a new catalog.
@@ -747,19 +747,17 @@
*Make modifications to products/variable.txt and catalog.cfg (e.g. CGI_URL, HOSTNAME, DBI_USER, DBI_PASSWORD).
-*Restart interchange.
+*Restart Interchange.
-N:One aspect of this local configuration is managing the differences between the main interchange daemon which runs on the CVS server and the local interchange daemon. The differences are probably hostname, database information, etc. That will all need to be managed (usually through catalog.cfg entries) and database exports & imports (i.e. the postgres pg_dump command).
+N:One aspect of this local configuration is managing the differences between the main Interchange daemon which runs on the CVS server and the local Interchange daemon. The differences are probably hostname, database information, etc. That will all need to be managed (usually through catalog.cfg entries) and database exports & imports (i.e. the postgres pg_dump command).
-N:Another thing that you might have noticed at this point is all the files that are modified locally by the interchange daemon will report ? or M when you run an update. This can be handled with {{F:CVSROOT/cvsignore}} and {{EX:$CVSIGNORE}}, which are beyond the scope of this document.
+N:Another thing that you might have noticed at this point is all the files that are modified locally by the Interchange daemon will report ? or M when you run an update. This can be handled with {{F:CVSROOT/cvsignore}} and {{EX:$CVSIGNORE}}, which are beyond the scope of this document.
#CVSIGNORE update
H2:Mailserver for CVS updates
-N:To setup a mailserver for CVS updates, first download and install mailman. For Red Hat systems, the following RPM could be used:
-
-*{{URL:ftp://speakeasy.rpmfind.net/linux/redhat/7.1/en/powertools/i386/RedHat/RPMS//mailman-2.0.1-2.i386.rpm}}
+N:To setup a mailserver for CVS updates, first download and install Mailman. For RPM-based systems, check on rpmfind.net for a precompiled binary package.
N:After installing, read the following information about Mailman and what needs to be done after installation (taken from the RPM meta data):
@@ -774,9 +772,9 @@
N:When the package has finished installing, you will need to:
* Run {{F:/var/mailman/bin/mmsitepass}}
- to set the mailman administrator password.
+ to set the Mailman administrator password.
* Edit {{F:/var/mailman/Mailman/mm_cfg.py}}
- to customize mailman's configuration for your site.
+ to customize Mailman's configuration for your site.
* Modify the sendmail configuration to ensure that it is running and
accepting connections from the outside world (to ensure that it runs,
set "DAEMON=yes" in /etc/sysconfig/sendmail, ensuring that it accepts
@@ -802,9 +800,9 @@
N:This is useful mostly to Windows users, since Linux users can just as easily run IC daemons on their own workstation as they can a separate server.
-N:The idea is to have the IC server use its own files and directories for things that won't be edited and modified locally, but reference a samba directory or NFS directory for things that will (such as {{F:pages/}}, {{F:templates/}}, etc.).
+N:The idea is to have the IC server use its own files and directories for things that won't be edited and modified locally, but reference a Samba directory or NFS directory for things that will (such as {{F:pages/}}, {{F:templates/}}, etc.).
-H3:Mount the samba or NFS directory
+H3:Mount the Samba or NFS directory
N:{{EX:smbmount <...>}} or {{EX:mount -t nfsfs <...>}}
@@ -822,19 +820,19 @@
F=templates; ln -s $S/$F $D/$F
!endblock
-N:This will leave you with a working catalog that can be quickly modified (since your editor can access the local copy), while interchange has to do the work of going over the SMB or NFS connection.
+N:This will leave you with a working catalog that can be quickly modified (since your editor can access the local copy), while Interchange has to do the work of going over the SMB or NFS connection.
-H2:jEdit - a good editor with Interchange/HTML/perl colorization and CVS
+H2:jEdit - a good editor with Interchange/HTML/Perl colorization and CVS
-N:I have been quite impressed with jEdit ({{URL:http://www.jedit.org}}, and open source editor that is written in java and runs on most platforms.
+N:I have been quite impressed with jEdit ({{URL:http://www.jedit.org}}, and open source editor that is written in Java and runs on most platforms.
-N:I use the interchange.xml language definition written by Chris Jesseman {{EMAIL:chris@sitemajic.net}}, which is available from {{URL:http://www.sitemajic.net/jedit/}}. With this, jEdit automatically colors HTML, perl, AND many interchange tags very intelligently.
+N:I use the interchange.xml language definition written by Chris Jesseman {{EMAIL:chris@sitemajic.net}}, which is available from {{URL:http://www.sitemajic.net/jedit/}}. With this, jEdit automatically colors HTML, Perl, AND many Interchange tags very intelligently.
N:Further, jEdit has a CVS plugin, written by Ben Sarsgard {{EMAIL:bsarsgard@vmtllc.com}}, and available at: {{URL:http://www.vmtllc.com/~bsarsgard/jedit.html}}. This plugin allows you to diff, update, and commit right from the editor.
-H2:Seperate servers for development and live catalogs
+H2:Separate servers for development and live catalogs
-N:If you have the luxury of seperate server hardware for the development and live catalogs, you might find the following utility helpful:
+N:If you have the luxury of separate server hardware for the development and live catalogs, you might find the following utility helpful:
*CVSviaFTP ({{URL:http://www.cvshome.org/dev/addoncvsftp.html}}) - from the CVS Add-ons page ({{URL:http://www.cvshome.org/dev/addons.html}}).
@@ -850,6 +848,7 @@
*May 2001. Conceived and written by Dan Browning.
*July 19, 2001. First draft complete, first public release.
+*12 April 2002. Minor typographical edit.
A1:Resources
@@ -867,24 +866,24 @@
*Pascal Molli's CVS reference site {{URL:http://www.loria.fr/~molli/cvs-index.html}}
*CVS Tutorial {{URL:http://cellworks.washington.edu/pub/docs/cvs/tutorial/cvs_tutorial_1.html}}
*CVS Tutorial 2 {{URL:http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/cvs/}}
-*RedHat CVS pserver setup guide {{URL:http://www.michael-amorose.com/cvs/}}
+*Red Hat CVS pserver setup guide {{URL:http://www.michael-amorose.com/cvs/}}
*CVS Add-ons {{URL:http://www.cvshome.org/dev/addons.html}}
A2:CVS Server Software
-*CVS RPM download (Red Hat 7.1) {{URL:ftp://speakeasy.rpmfind.net/linux/redhat/7.1/en/os/i386/RedHat/RPMS/cvs-1.11-3.i386.rpm}}
+*CVS RPM download (Red Hat Linux 7.1) {{URL:ftp://speakeasy.rpmfind.net/linux/redhat/7.1/en/os/i386/RedHat/RPMS/cvs-1.11-3.i386.rpm}}
-*Source tarballs links can can be found at cvshome.org.
+*Source tarball links can can be found at cvshome.org.
A2:CVS Client Software
-N:There are a variety of client access methods for using cvs on your development box.
+N:There is a variety of client access methods for using CVS on your development box.
*There are some great graphical clients for Linux, Windows, and Mac at {{URL:http://www.cvsgui.org}}. These also give you the same access to all the command line cvs commands.
-*jCVS is a great cross-platform graphical cvs client available at {{URL:http://www.jcvs.org}}.
+*jCVS is a great cross-platform graphical CVS client available at {{URL:http://www.jcvs.org}}.
-*jEdit is a great cross-platform text editor written in java, which not only has a CVS module that allows you to commit (upload) files directly from the editor, but also has a interchange markup language (and perl language) colorizer/parser. It is available from {{URL:http://www.jedit.org}}.
+*jEdit is a great cross-platform text editor written in java, which not only has a CVS module that allows you to commit (upload) files directly from the editor, but also has a Interchange Tag Language (and Perl language) colorizer/parser. It is available from {{URL:http://www.jedit.org}}.
Line:
1.8 +11 -11 docs/icadvanced.sdf
rev 1.8, prev_rev 1.7
Index: icadvanced.sdf
===================================================================
RCS file: /var/cvs/docs/icadvanced.sdf,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -u -r1.7 -r1.8
--- icadvanced.sdf 6 Dec 2001 03:27:27 -0000 1.7
+++ icadvanced.sdf 12 Apr 2002 22:53:18 -0000 1.8
@@ -1,10 +1,10 @@
!init OPT_LOOK="akopia"; OPT_STYLE="manual"
-# $Id: icadvanced.sdf,v 1.7 2001/12/06 03:27:27 jon Exp $
+# $Id: icadvanced.sdf,v 1.8 2002/04/12 22:53:18 jon Exp $
!define DOC_NAME "Advanced Interchange Topics"
!define DOC_TYPE ""
!define DOC_CODE "icadvanced"
-!define DOC_VERSION substr('$Revision: 1.7 $',11, -2)
+!define DOC_VERSION substr('$Revision: 1.8 $',11, -2)
!define DOC_STATUS "Draft"
!define DOC_PROJECT "Interchange"
!define DOC_URL "http://interchange.redhat.com/doc/icadvanced.html"
@@ -272,7 +272,7 @@
H3: Horizontal After Component
-This function allows the inclusion of a defined component to be displayed after or below the pages's content. It's called with the following code within the LEFTRIGHT_BOTTOM template:
+This function allows the inclusion of a defined component to be displayed after or below the page's content. It's called with the following code within the LEFTRIGHT_BOTTOM template:
!block example
[if scratch component_after]
@@ -289,7 +289,7 @@
H3: Special Tag
-This setting is only viable when a promotion is used for a horizontal component. It tells the promotional component which rows to evaluate in the merchandising table for display within the component. This setting normally corelates to the featured column of the merchandising table as follows:
+This setting is only viable when a promotion is used for a horizontal component. It tells the promotional component which rows to evaluate in the merchandising table for display within the component. This setting normally correlates to the featured column of the merchandising table as follows:
!block example
[query arrayref=main
@@ -438,7 +438,7 @@
H2: display tag and mv_metadata
-Interchange can store meta information for selected columns of tables in a site's database. This meta information is used when the user interacts with the database. For example, the meta informaton for a C<Hide Item> field might specify that a checkbox be displayed when the user edits that field, since the only reasonable values are C<on> and C<off>. Or, the meta information might specify a filter on data entered for a C<Filename> field which makes sure that the characters entered are safe for use in a filename.
+Interchange can store meta information for selected columns of tables in a site's database. This meta information is used when the user interacts with the database. For example, the meta information for a C<Hide Item> field might specify that a checkbox be displayed when the user edits that field, since the only reasonable values are C<on> and C<off>. Or, the meta information might specify a filter on data entered for a C<Filename> field which makes sure that the characters entered are safe for use in a filename.
C<Widget type> specifies the C<HTML INPUT> tag type to use when displaying the field in, say, the item editor.
@@ -794,7 +794,7 @@
H1: Link Programs
-Interchange requires a web server that is already installed on a system. It does have an internal server which can be used for administration, testing, and maintenance, but this will not be useful or desireable in a production environment.
+Interchange requires a web server that is already installed on a system. It does have an internal server which can be used for administration, testing, and maintenance, but this will not be useful or desirable in a production environment.
As detailed previously, Interchange is always running in the background as a daemon, or resident program. It monitors either a UNIX-domain file-based socket or a series of INET-domain sockets. The small CGI link program, called in the demo C<simple>, is run to connect to one of those sockets and provide the link to a browser.
@@ -942,7 +942,7 @@
perl -e 'do "syscfg"; system ("$CC $CFLAGS $DEFS $LIBS -o vlink vlink.c")'
!endblock
-There is also a C<compile_link> program which has docmentation embedded and which will compile an approprate link. If you cannot compile, try using the C<tlink.pl> script, written in Perl instead of C, which should work on most any system. Since vlink needs to have values set before compilation, a pre-compiled version will not work unless it has the exact values you need on your system. If you can use the defaults of 'localhost' and port 7786, you may be in luck.
+There is also a C<compile_link> program which has documentation embedded and which will compile an appropriate link. If you cannot compile, try using the C<tlink.pl> script, written in Perl instead of C, which should work on most any system. Since vlink needs to have values set before compilation, a pre-compiled version will not work unless it has the exact values you need on your system. If you can use the defaults of 'localhost' and port 7786, you may be in luck.
H1: Installing Perl Modules without Root Access
@@ -1002,20 +1002,20 @@
-If having trouble with the vlink program (named C<construct> in the demo configuration), try re-running C<makecat> and using INET mode instead. (Or copy the C<tlink> INET mode link program over C<vlink>). This should work unchanged for many systems.
--If using an ISP or have a non-standard network configuration, some changes to interchange.cfg are necessary. For C<tlink> to work, the proper host name(s) must be configured into the TcpHost directive in interchange.cfg. The program selects port 7786 by default (the ASCII codes for "M" and "V"). If another port is used, it must be set to the same number in both the tlink program (by running C<compile_link>) and the C<minivend.cfg> file. The C<tlink> program does not need to be SUID.
+-If using an ISP or have a non-standard network configuration, some changes to interchange.cfg are necessary. For C<tlink> to work, the proper host name(s) must be configured into the TcpHost directive in interchange.cfg. The program selects port 7786 by default (the ASCII codes for "M" and "V", for MiniVend). If another port is used, it must be set to the same number in both the tlink program (by running C<compile_link>) and the C<interchange.cfg> file. The C<tlink> program does not need to be SUID.
+Proper file permissions?
--The Interchange server should not run as the user C<nobody>! The program files can be owned by anyone, but any databases, ASCII database source files, error logs, and the directory that holds them must be writable by the proper user ID, that is the one that is executing the MiniVend program.
+-The Interchange server should not run as the user C<nobody>! The program files can be owned by anyone, but any databases, ASCII database source files, error logs, and the directory that holds them must be writable by the proper user ID, that is the one that is executing the Interchange program.
-The best way to operate in multi-user, multiple catalog setups is to create a special C<interch> user, then put that user in the group that contains each catalog user. If a group is defined for each individual user, this provides the best security. All associated files can be in 660 or 770 mode. There should be no problems with permissions and no problems with security.
+Is the C<vlink> program being executed on a machine that has the socket file C<etc/socket> on a directly attached disk?
--UNIX-domain sockets will not work on NFS-mounted file systems! This means that the server C<minivend> and the CGI program C<vlink> must be executing on the same machine.
+-UNIX-domain sockets will not work on NFS-mounted file systems! This means that the Interchange server and the CGI program C<vlink> must be executing on the same machine.
-The C<tlink> program does not have this problem, but it must have the proper host name(s) and TCP ports set in the TcpHost and TcpMap directives in C<interchange.cfg>. Also, be careful of security if sensitive information, like customer credit card numbers, is being placed on a network wire.
Line:
-N:Copyright 2001 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
+N:Copyright 2001-2002 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
1.14 +22 -22 docs/iccattut.sdf
rev 1.14, prev_rev 1.13
Index: iccattut.sdf
===================================================================
RCS file: /var/cvs/docs/iccattut.sdf,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -u -r1.13 -r1.14
--- iccattut.sdf 17 Sep 2001 17:24:10 -0000 1.13
+++ iccattut.sdf 12 Apr 2002 22:53:18 -0000 1.14
@@ -1,21 +1,21 @@
!init OPT_LOOK="akopia"; OPT_STYLE="manual"
-# $Id: iccattut.sdf,v 1.13 2001/09/17 17:24:10 jon Exp $
+# $Id: iccattut.sdf,v 1.14 2002/04/12 22:53:18 jon Exp $
!define DOC_NAME "Catalog-Building Tutorial"
!define DOC_TYPE ""
!define DOC_CODE "iccattut"
-!define DOC_VERSION substr('$Revision: 1.13 $', 11, -2)
+!define DOC_VERSION substr('$Revision: 1.14 $', 11, -2)
!define DOC_STATUS "Draft"
!define DOC_PROJECT "Interchange"
!define DOC_URL "http://interchange.redhat.com/doc/icadvanced.html"
-!define DOC_OWNER "2000-2001 Red Hat, Inc. E<lt>{{EMAIL:interchange@redhat.com}}E<gt>"
+!define DOC_OWNER "2000-2002 Red Hat, Inc. E<lt>{{EMAIL:interchange@redhat.com}}E<gt>"
!build_title
H1:Purpose
-N:The purpose of this document is to guide you through constructing a simple Interchange catalog from scratch. The demo catalog that ships with Interchange is quite complex since it highlights some of the many capabilities that Interchange offers. As a template for your own catalog, the demos can either be an intimidating place to start or too customized to relate to your business.
+N:The purpose of this document is to guide you through constructing a simple Interchange catalog from scratch. The demo catalog that ships with Interchange is quite complex since it highlights some of the many capabilities that Interchange offers. As a template for your own catalog, the demo can either be an intimidating place to start.
-The simple catalog you create using this tutorial should give you a feel for the basic Interchange system. It should also be considered a stepping stone to a more complete and functional e-commerce system built with Interchange. The tutorial relies as much as possible on default settings to accentuate how Interchange works. It will use as few of Interchange's capabilities as possible, while still building a usable store. The resulting site will be simple but usable. The value of this tutorial is not in the resulting e-commerce site, but in the instruction that occurs along the way.
+The simple catalog you create using this tutorial should give you a feel for the basic Interchange system. It should also be considered a stepping stone to a more complete and functional e-commerce system built with Interchange. The tutorial relies as much as possible on default settings to accentuate how Interchange works. It will use as few of Interchange's capabilities as possible, while still building a usable store. The resulting site will be simple but usable. The value of this tutorial is in the instruction that occurs along the way.
It is recommended that you create the files used in this tutorial yourself. You will learn more by creating the directory structure and using your favorite text editor to create files in the proper places on your own system as they are discussed.
@@ -25,21 +25,21 @@
H2:Install Interchange and the demo catalog
-N:The easiest way to get Interchange and the demo set up is through an {{1:RPM install}} on the Red Hat Linux or Linux Mandrake operating systems. You can also get Interchange by unpacking an Interchange tarball or checking out a copy of the CVS repository and doing a {{1:manual installation}}. These installations can be done either as a regular user or as root with a special Interchange user.
+N:The easiest way to get Interchange and the demo set up is through an {{1:RPM install}} on the Red Hat Linux or Linux Mandrake operating systems. You can also get Interchange by unpacking an Interchange tarball or checking out a copy of the CVS repository and doing a {{1:manual installation}}. These installations can be done either as a regular user or as root, installing for a special Interchange user.
-You must also know what type of installation you ran so you know where to place the various files created. Before proceeding, verify that Interchange is properly installed. Also, which type of installation you ran:
+You must also know what type of installation you ran so you know where to place the various files created. Before proceeding, verify that Interchange is properly installed. Also, keep in mind which type of installation you did:
*RPM (Red Hat Package Manager) install
*Manual install as root
*Manual install as regular user
-Note:After installation, {{FILE:makecat}} should be run to build your catalog. For information on installing Interchange and building your catalog using {{FILE:makecat}}, see the {{1:Red Hat Interchange 4.8: Getting Started Guide}}. Do not to continue with this tutorial without a working demo catalog.
+Note:After installation, {{FILE:makecat}} should be run to build your catalog. For information on installing Interchange and building your catalog using {{FILE:makecat}}, see the {{1:Interchange Getting Started Guide}}. Do not to continue with this tutorial without a working demo catalog.
N:Installing the demo catalog set up the Interchange global configuration file {{FILE:interchange.cfg}}, which resides in the Interchange software directory. Also, it compiled the link program for your specific server and placed the executable program in your cgi-bin directory. This is necessary for your catalog to run properly.
H2:The Interchange operating system user
-N:If Interchange was installed as a regular user, that will be the user Interchange runs as. If Interchange was installed as root or from an RPM, you need to know the name of the separate Interchange user. The Interchange daemon will not run as root, or even as the web server user (often www or httpd or nobody). If Interchange was installed from the RPM, or with the default source installation settings, the default username is {{EX:interch}}. If a different user name was established, you will need to know what it is.
+N:If Interchange was installed as a regular user, that will be the user Interchange runs as. If Interchange was installed as root or from an RPM, you need to know the name of the separate Interchange user. The Interchange daemon will not run as root, and should not run as the web server user (usually 'apache', 'www', 'httpd', or 'nobody'). If Interchange was installed from the RPM, or with the default source installation settings, the username is {{EX:interch}}. If you selected a different user name, you will need to know what it is.
H2:Important directories
@@ -56,8 +56,7 @@
{{B:.Manual install as regular user:}} /home/username/catalogs
*cgi-bin directory
-{{B:.RPM install or source install as root (Red Hat 6, Linux Mandrake):}} /home/httpd/cgi-bin
-{{B:.RPM install or source install as root (Red Hat 7):}} /var/www/cgi-bin
+{{B:.RPM install or source install as root:}} /var/www/cgi-bin
{{B:.Manual install as root (locally installed web server):}} /usr/local/htdocs, /opt/www, ...
{{B:.Manual install as regular user:}} /home/username/public_html (with .cgi extension)
@@ -87,7 +86,7 @@
H2:Tutorial assumptions
-N:Because it is impossible to cover all senarios, this tutorial assumes that you installed Interchange on Red Hat 7 from the RPM. This creates the following settings:
+N:Because it is impossible to cover all scenarios, this tutorial assumes that you installed Interchange on Red Hat Linux from the RPM packages. This creates the following settings:
*{{B:Interchange software directory:}} /usr/lib/interchange
*{{B:Catalogs directory:}} /var/lib/interchange
@@ -134,7 +133,7 @@
H2:Become the Interchange user
-N:You should be able to do everything you need to do as the 'interch' user for the rest of this tutorial. So you can switch to that user now ({{EX:su interch}}). If you installed Interchange from the RPM, the user {{B:interch}} probably doesn't have a password. You'll have to set it with a command such as {{EX:passwd interch}} while root.
+N:You should be able to do everything you need to do as the 'interch' user for the rest of this tutorial. So you can switch to that user now ({{EX:su - interch}}). If you installed Interchange from the RPM, the user {{B:interch}} probably doesn't have a password. You'll have to set it with a command such as {{EX:passwd interch}} while root.
H2:Go to the tutorial catalog directory
@@ -144,7 +143,7 @@
H2:Create the session directory
-N:You need to create the session directory where Interchange saves information on each visitor's browsing session. If you do not have this directory, Interchange may fail to work. This directory is called {{FILE:session/}} and goes under your catalog directory. Type {{EX:mkdir session}} to create this directory.
+N:You need to create the session directory where Interchange saves information on each visitor's browsing session. If you do not have this directory, your catalog will not work. This directory is called {{FILE:session/}} and goes under your catalog directory. Type {{EX:mkdir session}} to create this directory.
H1:Configuration files
@@ -178,11 +177,11 @@
E: Database name filename format
-N:Interchange has several database options available. We will use the simplest, which is the built-in default (specifically, some variant of DBM). The default location for {{1:filename}} is in a subdirectory called {{FILE:products}} under the catalog directory. Interchange recongnizes a number of file formats. We will use a tab-delimited text file. Enter the following into {{FILE:catalog.cfg}}:
+N:Interchange has several database options available. We will use the simplest, which is the built-in default (specifically, some variant of DBM). The default location for {{1:filename}} is in a subdirectory called {{FILE:products}} under the catalog directory. Interchange recognizes a number of file formats. We will use a tab-delimited text file. Enter the following into {{FILE:catalog.cfg}}:
E: Database products products.txt TAB
-N:This tells Interchange that you have a database table named 'products' that is described in a tab-delimited file named {{FILE:products.txt}}. You can describe an unlimited number of arbitrary database tables for the system to use this way. Interchange is an e-commerce system and it expects at least a products database table. You can specify all of the database tables that contain products by using the {{2:ProductFiles}} directive. There is no default for this, so you will have to specify your products database by adding the following line to {{FILE:catalog.cfg}}:
+N:This tells Interchange that you have a database table named 'products' that is described in a tab-delimited file named {{FILE:products.txt}}. You can describe an unlimited number of arbitrary database tables for the system to use this way. Interchange keeps a list of default tables called "Product Files," reflecting its e-commerce roots. You can specify all of the database tables that contain products by using the {{2:ProductFiles}} directive. There is no default for this, so you will have to specify your products table's name by adding the following line to {{FILE:catalog.cfg}}:
E: ProductFiles products
@@ -212,7 +211,7 @@
N:The {{FILE:products/products.txt}} file will serve two purposes. It will provide Interchange with the layout of the products database table and it will also provide the data. When Interchange parses the products.txt file, it will expect the first line to contain the names of the fields for the database table (for example, sku, description, price). The first field in the list is expected to be a primary key (unique identifier) for that row. In most cases you are going to use the SKU (stock keeping unit) as the unique identifier for each product.
-N:The product database is handled as a special case since Interchange expects at least the description, price, and product ID (sku) fields. In other words, the {{FILE:products.txt}} file must at least contain fields named sku, price, and description. Any other fields you decide to include are handled normally.
+N:The product database is handled as a special case since Interchange expects at least the description, price, and product ID (sku) fields. In other words, the {{FILE:products.txt}} file must at least contain fields named sku, price, and description. You can have other fields too, if you wish.
N:The simple store that we are going to build will sell tests. You can choose another sample product line, but it is recommended that you keep it simple. Create the file {{FILE:products/products.txt}} to look like this, with a single tab separating each field:
@@ -224,7 +223,7 @@
1299 Ubiquitous diff eq final 37.00
!endblock
-Note:When using tab-delimited files as we are, make sure you have exactly one tab between each field. Some text editors will use spaces to simulate tabs. Interchange expects actual ASCII tab characters; no spaces or extra characters are accepted.
+Note:When using tab-delimited files as we are, make sure you have exactly one tab between each field. Some text editors will use spaces to simulate tabs. Interchange expects actual ASCII tab characters; extra spaces or other characters will corrupt your data.
N:You may notice that the columns don't line up in your text editor. This is the nature of tab-delimited files. Do not try to fix these.
@@ -248,7 +247,7 @@
|_____________________|
!endblock
-N:The "main" section holds the content that is different for each page. The "top" section is for headers, banners, menus, and so on. The "left" section can be used as a sidebar or navagation bar, and the "bottom" section can contain the copyright and contact info. The top, left, and bottom sections will remain constant throughout the site. Making a change to information in one of these sections will make that change to all pages in your site.
+N:The "main" section holds the content that is different for each page. The "top" section is for headers, banners, menus, and so on. The "left" section can be used as a sidebar or navigation bar, and the "bottom" section can contain the copyright and contact info. The top, left, and bottom sections will remain constant throughout the site. Making a change to information in one of these sections will make that change to all pages in your site.
N:Now type the HTML for each template section in an individual plain text file in the catalog directory, named 'top', 'left', and 'bottom', respectively using the code displayed below. No '.html' suffixes are used on these because they are not meant to be parsed directly by Interchange as full pages.
@@ -307,7 +306,7 @@
N:Restart Interchange so your changes take effect. Go to your web browser and load the page. The URL should be similar to the following: {{EX:http://localhost/cgi-bin/tutorial/index.html}}.
-Note:Interchange pages in the {{FILE:pages/}} or other directories {{B:must}} have the .html suffix on them. You can drop the suffix in your URL and in other places, such as the [page] tag you'll learn about later, but the file name itself must have the suffix.
+Note:Interchange pages in the {{FILE:pages/}} or other directories {{B:must}} have the .html suffix on them. You can drop the suffix in your URL and in other places, such as the [page] tag you'll learn about later, but the file name on disk must have the suffix.
H1:Troubleshooting
@@ -936,7 +935,7 @@
E: [loop search="ra=yes/fi=products/tf=1/to=r"]
-N:Now let's try narrowing the search down a bit. Instead of returning all, we'll give 'se', the {{B:se}}arch paramerter, and and use 'su', which allows {{B:su}}bstring matches. To search only for products that have the word "test" in one of their fields, and sort the results by description, type:
+N:Now let's try narrowing the search down a bit. Instead of returning all, we'll give 'se', the {{B:se}}arch parameter, and and use 'su', which allows {{B:su}}bstring matches. To search only for products that have the word "test" in one of their fields, and sort the results by description, type:
E: [loop search="se=test/su=yes/fi=products/tf=description"]
@@ -1109,7 +1108,8 @@
N:December 2000. Edited and expanded by Jon Jensen.
N:January 2001. Proofread and clarified by Alison Smith and David Adams.
N:12 January 2001. First public release.
+N:12 April 2002. Remove mention of obsolete Red Hat Linux 6-specific RPMs.
Line:
-N:Copyright 2001 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
+N:Copyright 2001-2002 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
1.60 +11 -11 docs/icconfig.sdf
rev 1.60, prev_rev 1.59
Index: icconfig.sdf
===================================================================
RCS file: /var/cvs/docs/icconfig.sdf,v
retrieving revision 1.59
retrieving revision 1.60
diff -u -u -r1.59 -r1.60
--- icconfig.sdf 1 Apr 2002 14:54:51 -0000 1.59
+++ icconfig.sdf 12 Apr 2002 22:53:18 -0000 1.60
@@ -1,10 +1,10 @@
!init OPT_LOOK="akopia"; OPT_STYLE="manual"
-# $Id: icconfig.sdf,v 1.59 2002/04/01 14:54:51 racke Exp $
+# $Id: icconfig.sdf,v 1.60 2002/04/12 22:53:18 jon Exp $
!define DOC_NAME "Configuration Reference"
!define DOC_TYPE ""
!define DOC_CODE "icconfig"
-!define DOC_VERSION substr('$Revision: 1.59 $',11, -2)
+!define DOC_VERSION substr('$Revision: 1.60 $',11, -2)
!define DOC_STATUS "Draft"
!define DOC_PROJECT "Interchange"
!define DOC_URL "http://interchange.redhat.com/doc/icadvanced.html"
@@ -12,13 +12,13 @@
H1: Interchange Configuration Files
-The Red Hat Interchange 4.8 Configuration Reference is an alphabetical reference to the configuration directives used in Interchange global and catalog configuration files.
+This is an alphabetical reference to the configuration directives used in Interchange global and catalog configuration files.
Interchange has multiple catalog capability, and therefore splits its configuration into two pieces. One is global, C<interchange.cfg>, and affects every catalog running under it. The other, C<catalog.cfg> is specific to an individual catalog, and has no effect on other catalogs.
H2: Directive syntax
-Configuration directives are normally specified with the directive as the first word on the line, with its value or values following. Capitalization of the directive name is not signifigant. Leading and trailing whitespace is stripped from the line.
+Configuration directives are normally specified with the directive as the first word on the line, with its value or values following. Capitalization of the directive name is not significant. Leading and trailing whitespace is stripped from the line.
LI1: Including files in directives
@@ -225,7 +225,7 @@
H2: CheckHTML *global*
-Set to the name of an external program that will check the users HTML when they set C<[flag checkhtml]> or C<[tag flag checkhtml][/tag]> in their page.
+Set to the name of an external program that will check the user's HTML when they set C<[flag checkhtml]> or C<[tag flag checkhtml][/tag]> in their page.
!block example
CheckHTML /usr/local/bin/weblint
@@ -594,7 +594,7 @@
H2: PIDfile *global*
The file which will contain the Interchange server process ID so that
-it can be read to determine which proces should be sent a signal for
+it can be read to determine which process should be sent a signal for
stopping or reconfiguring the server.
!block example
@@ -933,7 +933,7 @@
H2: VarName *global*
-Sets the names of variables that will be remapped to and from the URL when Interchange writes it. For instance, to display the variable C<mv_session_id> as C<session> in the users URL:
+Sets the names of variables that will be remapped to and from the URL when Interchange writes it. For instance, to display the variable C<mv_session_id> as C<session> in the user's URL:
!block example
VarName mv_session_id session
@@ -1270,7 +1270,7 @@
.Set by Interchange to true, or 1, if the the card validates properly. Set to 0 otherwise.
-PGP is recommended as the encryption program, though remember that U.S. commercial organizations may require a license for RSA. Interchange will work with GPG, the Gnu Privacy Guard.
+GnuPG is recommended as the encryption program. Interchange will also work with PGP.
!block example
CreditCardAuto Yes
@@ -1534,7 +1534,7 @@
ImageDirSecure /secure/images/
!endblock
-This is useful if using separate HTTPS and HTTP servesr, and cannot make the image directory path heads match.
+This is useful if using separate HTTPS and HTTP servers, and cannot make the image directory path heads match.
H2: Locale
@@ -2128,7 +2128,7 @@
GDBM GDBM
!endblock
-The default is file-based sessions, which provides the best performance and reliablility in most environments.
+The default is file-based sessions, which provides the best performance and reliability in most environments.
If you are planning on running Interchange servers with an NFS-mounted filesystem as the session target, you must set SessionType to "NFS". The other requisites are usually:
@@ -2458,4 +2458,4 @@
Line:
-N:Copyright 2001 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
+N:Copyright 2001-2002 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
1.39 +4 -4 docs/icdatabase.sdf
rev 1.39, prev_rev 1.38
Index: icdatabase.sdf
===================================================================
RCS file: /var/cvs/docs/icdatabase.sdf,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -u -r1.38 -r1.39
--- icdatabase.sdf 1 Apr 2002 16:09:10 -0000 1.38
+++ icdatabase.sdf 12 Apr 2002 22:53:18 -0000 1.39
@@ -1,10 +1,10 @@
!init OPT_LOOK="akopia"; OPT_STYLE="manual"
-# $Id: icdatabase.sdf,v 1.38 2002/04/01 16:09:10 kwalsh Exp $
+# $Id: icdatabase.sdf,v 1.39 2002/04/12 22:53:18 jon Exp $
!define DOC_NAME "Interchange Databases"
!define DOC_TYPE ""
!define DOC_CODE "icdatabase"
-!define DOC_VERSION substr('$Revision: 1.38 $',11, -2)
+!define DOC_VERSION substr('$Revision: 1.39 $',11, -2)
!define DOC_STATUS "Draft"
!define DOC_PROJECT "Interchange"
!define DOC_URL "http://interchange.redhat.com/doc/icadvanced.html"
@@ -147,7 +147,7 @@
LI2: shipping.asc
-..The database of shipping options that is accessed if the C<CustomShipping> directive is in use. This is a fixed-format database, and must be created as specified. For more information, see the Shipping ITL tag in the {{1:Red Hat Interchange 4.8: Tag Reference Guide}}.
+..The database of shipping options that is accessed if the C<CustomShipping> directive is in use. This is a fixed-format database, and must be created as specified. For more information, see the Shipping ITL tag in the {{1:Interchange Tag Reference Guide}}.
LI2: salestax.asc
@@ -3790,4 +3790,4 @@
Line:
-N:Copyright 2001 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
+N:Copyright 2001-2002 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
1.8 +49 -66 docs/icfaq.sdf
rev 1.8, prev_rev 1.7
Index: icfaq.sdf
===================================================================
RCS file: /var/cvs/docs/icfaq.sdf,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -u -r1.7 -r1.8
--- icfaq.sdf 21 Dec 2001 03:30:08 -0000 1.7
+++ icfaq.sdf 12 Apr 2002 22:53:18 -0000 1.8
@@ -1,13 +1,13 @@
!init OPT_LOOK="akopia"; OPT_STYLE="manual"
-# $Id: icfaq.sdf,v 1.7 2001/12/21 03:30:08 danb Exp $
+# $Id: icfaq.sdf,v 1.8 2002/04/12 22:53:18 jon Exp $
!define DOC_NAME "Frequently Asked Questions"
!define DOC_TYPE ""
!define DOC_CODE "icfaq"
-!define DOC_VERSION substr('$Revision: 1.7 $',11, -2)
+!define DOC_VERSION substr('$Revision: 1.8 $',11, -2)
!define DOC_STATUS "Draft"
!define DOC_PROJECT "Interchange"
-!define DOC_URL "http://developer.akopia.com/doc/icfaq.html"
+!define DOC_URL "http://interchange.redhat.com/doc/icfaq.html"
!build_title
H1: How does Interchange work?
@@ -843,14 +843,11 @@
This URL:
-!block example
- C<<>A HREF="http://yourcatalog.com/cgi-in/yourcat/sp_offer?mv_pc=Source1">
- Special offer!</A>
-!endblock
+E:http://yourcatalog.com/cgi-in/yourcat/sp_offer?mv_pc=Source1
will yield C<Source1> from the Interchange tag [data session source].
-The Interchange 3 idiom C<?;;Source1> continues to be supported, so existing partner sites should work without change.
+The Minivend 3 idiom C<?;;Source1> continues to be supported, so existing partner sites should work without change.
H2: How can I send an email copy of the receipt to a user?
@@ -1605,7 +1602,7 @@
IC daemon user should have environment variables ORACLE_HOME and
possibly NLS_LANG set.
-Mark Johnson (Red Hat E-Business Professional Services) wrote this
+Mark Johnson (Red Hat Professional Services) wrote this
trigger on TABLE_NAME to update the MOD_TIME column on insert or update.
The user must have been granted the RESOURCE role to create triggers.
Here it is:
@@ -1683,77 +1680,64 @@
H1: Perl/Interchange FAQ
-!block example
-Date: Wed, 14 Feb 2001 10:20:18 -0600
-From: Cameron B. Prince <cameron@akopia.com>
-To: support@akopia.com
-Subject: Local Perl Install Steps
-
-Hi all,
-
-Here's the steps I took to install the local perl for the client who had an
-old system perl (5.004) and couldn't upgrade.
-
-This was tested on a Red Hat v5.x system as well as v7.0.
-
-Cameron
-
+H2: Cameron Prince's local Perl installation how-to
-1) Login as user. In this example, we'll call the user bob. Bob's home directory is /home/bob.
++Login as user. In this example, we'll call the user bob. Bob's home directory is /home/bob.
-2) Get the perl tarball and extract it in /home/bob. (tar -xzvf perl-5.6.0.tar.gz)
++Get the perl tarball and extract it in /home/bob. (tar -xzvf perl-5.6.0.tar.gz)
-3) Create a directory for the local perl. (mkdir /home/bob/local-perl)
++Create a directory for the local perl. (mkdir /home/bob/local-perl)
-4) Compile perl.
++Compile perl.
- A) cd perl-5.6.0
+++cd perl-5.6.0
- B) sh Configure
+++sh Configure
- C) Choose all the defaults until you get to: "Directories to use for library searches?" Here you want to enter the new local perl path, as well as the defaults. So you should enter something like: /home/bob/local-perl/lib /usr/local/lib /lib /usr/lib
+++Choose all the defaults until you get to: "Directories to use for library searches?" Here you want to enter the new local perl path, as well as the defaults. So you should enter something like: /home/bob/local-perl/lib /usr/local/lib /lib /usr/lib
- D) Continue choosing defaults till you get to: "Any additional ld flags (NOT including libraries)?" This should be: -L/home/bob/local-perl/lib
+++Continue choosing defaults till you get to: "Any additional ld flags (NOT including libraries)?" This should be: -L/home/bob/local-perl/lib
- E) Continue choosing defaults till you get to: "Installation prefix to use? (~name ok)" This should be: /home/bob/local-perl
+++Continue choosing defaults till you get to: "Installation prefix to use? (~name ok)" This should be: /home/bob/local-perl
- F) Choose all defaults till you get to: "Directory /home/bob/local-perl/bin doesn't exist. Use that name anyway?" Enter y.
+++Choose all defaults till you get to: "Directory /home/bob/local-perl/bin doesn't exist. Use that name anyway?" Enter y.
- G) Continue choosing defaults till you get to: "Do you want to install perl as /usr/bin/perl?" Enter n.
+++Continue choosing defaults till you get to: "Do you want to install perl as /usr/bin/perl?" Enter n.
- H) Continue choosing defaults till you get to: "Directory /home/bob/local-perl/bin doesn't exist. Use that name anyway?" Enter y.
+++Continue choosing defaults till you get to: "Directory /home/bob/local-perl/bin doesn't exist. Use that name anyway?" Enter y.
- I) Directory /home/bob/local-perl/bin doesn't exist. Use that name anyway? Enter y.
+++Directory /home/bob/local-perl/bin doesn't exist. Use that name anyway? Enter y.
- J) Continue taking defaults till you return to a prompt.
+++Continue taking defaults till you return to a prompt.
- K) make
+++make
- L) make test
+++make test
- M) make install
+++make install
- O) /home/bob/local-perl/bin/perl -v
++/home/bob/local-perl/bin/perl -v
- You should see: This is perl, v5.6.0
+.You should see: This is perl, v5.6.0
-5) edit /home/bob/.bash_rc
++edit /home/bob/.bash_rc
- Change: PATH=$PATH:$HOME/bin
- To: PATH=/home/bob/local-perl/bin:$PATH:$HOME/bin
+.Change: PATH=$PATH:$HOME/bin
+.To: PATH=/home/bob/local-perl/bin:$PATH:$HOME/bin
-6) Logout and log back in.
++Logout and log back in.
-7) which perl
++which perl
- You should see: ~/local-perl/bin/perl or /home/bob/local-perl/bin/perl
+.You should see: ~/local-perl/bin/perl or /home/bob/local-perl/bin/perl
-8) perl -MCPAN -e 'install Bundle::Interchange'
++perl -MCPAN -e 'install Bundle::Interchange'
-Keep running this until you see:
+.Keep running this until you see:
+!block example
MD5 is up to date.
MIME::Base64 is up to date.
URI is up to date.
@@ -1771,27 +1755,26 @@
Storable is up to date.
DBI is up to date.
Safe::Hole is up to date.
+!endblock
You may need to get the modules via ftp and install them by hand. For instance, during the test used to create this document, I had to get URI and LWP and install by hand before everything reported that it was up to date. To do this, follow these steps:
-1) ftp ftp.cpan.org
-2) cd /CPAN/modules/by-module/URI
-3) bin
-4) get URI-1.10.tar.gz
-5) quit
-6) tar -xzvf URI-1.10.tar.gz
-7) cd URI-1.10
-8) perl Makefile.pl
-9) make
-10) make test
-11) make install
+++ftp ftp.cpan.org
+++cd /CPAN/modules/by-module/URI
+++bin
+++get URI-1.10.tar.gz
+++quit
+++tar -xzvf URI-1.10.tar.gz
+++cd URI-1.10
+++perl Makefile.pl
+++make
+++make test
+++make install
Use the same basic steps for any module not properly installed by using perl -MCPAN -e 'install Bundle::Interchange'
-
-9) Install Interchange as normal.
-!endblock
+Now, install Interchange as normal.
Line:
-N:Copyright 2001 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
+N:Copyright 2001-2002 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
1.25 +4 -4 docs/icfoundation.sdf
rev 1.25, prev_rev 1.24
Index: icfoundation.sdf
===================================================================
RCS file: /var/cvs/docs/icfoundation.sdf,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -u -r1.24 -r1.25
--- icfoundation.sdf 29 Dec 2001 21:31:13 -0000 1.24
+++ icfoundation.sdf 12 Apr 2002 22:53:18 -0000 1.25
@@ -1,10 +1,10 @@
!init OPT_LOOK="akopia"; OPT_STYLE="manual"
-# $Id: icfoundation.sdf,v 1.24 2001/12/29 21:31:13 jon Exp $
+# $Id: icfoundation.sdf,v 1.25 2002/04/12 22:53:18 jon Exp $
!define DOC_NAME "Foundation Store"
!define DOC_TYPE ""
!define DOC_CODE "icfoundation"
-!define DOC_VERSION substr('$Revision: 1.24 $', 11, -2)
+!define DOC_VERSION substr('$Revision: 1.25 $', 11, -2)
!define DOC_STATUS "Draft"
!define DOC_PROJECT "Interchange"
!define DOC_URL "http://interchange.redhat.com/doc/icfoundation.html"
@@ -1806,7 +1806,7 @@
H2: access.asc
-Administrative access table. This table is used by the Administration Tool. For more description on these fields, see the Red Hat Interchange Administration Tool guide.
+Administrative access table. This table is used by the Administration Tool. For more description on these fields, see the Interchange Administration Tool guide.
B<Fields>
@@ -4211,4 +4211,4 @@
Line:
-N:Copyright 2001 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
+N:Copyright 2001-2002 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
1.77 +4 -4 docs/ictags.sdf
rev 1.77, prev_rev 1.76
Index: ictags.sdf
===================================================================
RCS file: /var/cvs/docs/ictags.sdf,v
retrieving revision 1.76
retrieving revision 1.77
diff -u -u -r1.76 -r1.77
--- ictags.sdf 18 Feb 2002 00:41:59 -0000 1.76
+++ ictags.sdf 12 Apr 2002 22:53:18 -0000 1.77
@@ -1,14 +1,14 @@
!init OPT_LOOK="akopia"; OPT_STYLE="manual"
-# $Id: ictags.sdf,v 1.76 2002/02/18 00:41:59 mheins Exp $
+# $Id: ictags.sdf,v 1.77 2002/04/12 22:53:18 jon Exp $
!define DOC_NAME "Interchange Tags Reference"
!define DOC_TYPE ""
!define DOC_CODE "ictags"
-!define DOC_VERSION substr('$Revision: 1.76 $', 11, -2)
+!define DOC_VERSION substr('$Revision: 1.77 $', 11, -2)
!define DOC_STATUS "Draft"
!define DOC_PROJECT "Interchange"
!define DOC_URL "http://interchange.redhat.com/doc/ictags.html"
-!define DOC_OWNER "1996-2001 Red Hat, Inc. {{EMAIL:interchange@redhat.com}}"
+!define DOC_OWNER "1996-2002 Red Hat, Inc. {{EMAIL:interchange@redhat.com}}"
!define SHOW_COMMENTS 0
!define EXAMPLE_SESSION "6CZ2whqo"
@@ -16513,4 +16513,4 @@
Line:
-N:Copyright 2001 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
+N:Copyright 2001-2002 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
1.33 +4 -4 docs/ictemplates.sdf
rev 1.33, prev_rev 1.32
Index: ictemplates.sdf
===================================================================
RCS file: /var/cvs/docs/ictemplates.sdf,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -u -r1.32 -r1.33
--- ictemplates.sdf 18 Feb 2002 00:41:59 -0000 1.32
+++ ictemplates.sdf 12 Apr 2002 22:53:18 -0000 1.33
@@ -1,10 +1,10 @@
!init OPT_LOOK="akopia"; OPT_STYLE="manual"
-# $Id: ictemplates.sdf,v 1.32 2002/02/18 00:41:59 mheins Exp $
+# $Id: ictemplates.sdf,v 1.33 2002/04/12 22:53:18 jon Exp $
!define DOC_NAME "Template Guide"
!define DOC_TYPE ""
!define DOC_CODE "ictemplates"
-!define DOC_VERSION substr('$Revision: 1.32 $',11, -2)
+!define DOC_VERSION substr('$Revision: 1.33 $',11, -2)
!define DOC_STATUS "Draft"
!define DOC_PROJECT "Interchange"
!define DOC_URL "http://interchange.redhat.com/doc/ictemplates.html"
@@ -38,7 +38,7 @@
C<@_VARIABLENAME_@> is replaced by the catalog variable VARIABLENAME if it exists; otherwise, it is replaced by the global variable VARIABLENAME.
-For more information on how to use the C<Variable> configuration file directive to set global variables in C<interchange.cfg> and catalog variables in C<catalog.cfg>, see the {{1:Red Hat Interchange 4.8: Development Guide}}.
+For more information on how to use the C<Variable> configuration file directive to set global variables in C<interchange.cfg> and catalog variables in C<catalog.cfg>, see the {{1:Interchange Configuration Guide}}.
H1: Using Interchange Template Tags
@@ -3257,4 +3257,4 @@
Line:
-N:Copyright 2001 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
+N:Copyright 2001-2002 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
1.17 +4 -4 docs/icupgrade.sdf
rev 1.17, prev_rev 1.16
Index: icupgrade.sdf
===================================================================
RCS file: /var/cvs/docs/icupgrade.sdf,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -u -r1.16 -r1.17
--- icupgrade.sdf 17 Sep 2001 17:24:11 -0000 1.16
+++ icupgrade.sdf 12 Apr 2002 22:53:18 -0000 1.17
@@ -1,14 +1,14 @@
!init OPT_LOOK="akopia"; OPT_STYLE="manual"
-# $Id: icupgrade.sdf,v 1.16 2001/09/17 17:24:11 jon Exp $
+# $Id: icupgrade.sdf,v 1.17 2002/04/12 22:53:18 jon Exp $
!define DOC_NAME "Interchange Upgrade Guide"
!define DOC_TYPE ""
!define DOC_CODE "icupgrade"
-!define DOC_VERSION substr('$Revision: 1.16 $', 11, -2)
+!define DOC_VERSION substr('$Revision: 1.17 $', 11, -2)
!define DOC_STATUS "Draft"
!define DOC_PROJECT "Interchange"
!define DOC_URL "http://interchange.redhat.com/doc/icupgrade.html"
-!define DOC_OWNER "1996-2001 Red Hat, Inc. E<lt>{{EMAIL:interchange@redhat.com}}E<gt>"
+!define DOC_OWNER "1996-2002 Red Hat, Inc. E<lt>{{EMAIL:interchange@redhat.com}}E<gt>"
!build_title
H1:Introduction
@@ -944,4 +944,4 @@
Line:
-N:Copyright 2001 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.
+N:Copyright 2001-2002 Red Hat, Inc. Freely redistributable under terms of the GNU General Public License.