How to Use WebCLIPS

- Table of Contents -

  1. Overview
  2. Starting a WebCLIPS screen from HTML
  3. WebCLIPS.ini
  4. Static vs Dynamic Mode
  5. Multi-Screen Navigation
  6. Static Screen User Interaction and passing data from HTML to CLIPS
  7. Using HTML Helper functions to generate screens in a CLIPS program
  8. How facts are passed
  9. Debugging CLIPS programs and re-routing output from CLIPS programs
  10. Administration issues
  11. Reserved fact and deftemplate names
  12. References

Overview

WebCLIPS is an implementation of CLIPS [1] run as a CGI application under Windows NT/95 [2] . WebCLIPS utilizes the CLIPS Dynamic Link Library [3] to automate a typical run of a CLIPS program (i.e. load, reset and run). The WebCLIPS scripts are standard to the CLIPS specification. The only 'unusual' element is that the results generated from WebCLIPS screens have some embedded HTML [4] tags to properly display the output.

The basic building block of WebCLIPS is the screen. The screen-name dictates how CLIPS should run a particular program (i.e. which rules to use, which facts to use etc.). WebCLIPS makes use of a Win32 API called GetPrivateProfileString. The screen-name is the name of the section for the INI file and the parameters passed to the CLIPS program (facts, rules etc.) are entries for that screen-name (section). For example, the Monkey and Bananas Demo could look like this : 

[Monkey and Bananas Demo]

script1=c:\clips\examples\mab.clp

InitialScreen=c:\htmldocs\mab.htm

PreserveFacts=Yes
In the above example the name of the screen is Monkey and Bananas Demo, it uses one script, it displays an HTML document and uses it to interact with the user and the fact-state is carried forward to other screens. In this way WebCLIPS supports multi-screen input. Facts can be gathered and passed to subsequent screens for further processing.

Go to Table of Contents

Starting a WebCLIPS screen from HTML

Since WebCLIPS is a standard CGI application, it needs no special treatment save for passing the screen-name to run. This can be done in any fashion where the data from the web server comes in the following format : fact&Screen+to+be+run. Here are two HTML examples to help you get started :

(1)

<FORM ACTION=/cgi-bin/WebCLIPS.EXE METHOD=POST>

<INPUT TYPE="hidden" NAME="fact" VALUE="(ScreenName (ScrnName Monkey and Bananas Demo))">

<center>

<INPUT TYPE="submit" VALUE="Get Those Bananas!">

</center>

</FORM>

(2)

<FORM ACTION="/cgi-bin/WebCLIPS.EXE" METHOD="GET">

<SELECT NAME="fact">

<OPTION VALUE="(ScreenName (ScrnName Baseball Demo))">BaseBall Demo (who's on first?)

<OPTION VALUE="(ScreenName (ScrnName Monkey and Bananas Demo))">Classic Monkey and Bananas Demo

</SELECT>

<INPUT TYPE="submit">

</FORM>

Go to Table of Contents

WebCLIPS.ini

WebCLIPS.INI is a configuration file used by WebCLIPS to determine how to run a particular screen (i.e. CLIPS program). There are several parameters that you can pass to a screen :

  1. script - This entry is the name of a text file passed to a CLIPS program using the load command. You can pass multiple scripts to a screen. The format of this entry is :

    scriptX=filename where X is a seq. number. The first script is 1, the second is 2 etc.

    For example, Script1=c:\clips\examples\mab.clp

  2. fact - This entry asserts a fact to a CLIPS program. It is limited to a single line. You can pass multiple facts to a screen. The format of this entry is :

    FactX=(<RHS pattern>+) where X is a seq. number. The first fact is 1, the second is 2 etc.

    For example, fact1=(Print-Phase (phase Header))

  3. factgroup - This entry is the name of a text file containing facts that are passed to a CLIPS program using the load-facts command. You can pass multiple factgroups to a screen. The format of this entry is :

    factgroupX=filename where X is a seq. number. The first factgroup is 1, the second is 2 etc.

    For example, factgroup1=c:\monitor\valves\status.clp

  4. ODBCQuery - This entry asserts facts to a CLIPS program using the CLIPS/ODBC Interface [5]. It is limited to a single line. You can issue multiple ODBC queries to a screen. The format of this entry is : 

    ODBCQueryX=(ODBCQuery (query|file SQL_Query|filename) (connect ODBC_Connect_Info) (deftemplatename deftemplate) (ImplodeData Y | N))
    where X is a seq. number. The first ODBC query is 1, the second is 2 etc.

    For example, 

    ODBCQuery1=(ODBCQuery (query select * from MALE) (deftemplatename male) (connect DSN=CLIPSODBC;) (implodedata Y))

    The purpose of the implodedata slot is to tell the interface how to assert the fact. If implodedata is set to Y, then all data fetched from the query will be wrapped in double quotes ("") and asserted as single-slot type.

  5. BinImage - This entry is the name of a binary image file passed to a CLIPS program using the bload command. This binary image file must be created using bsave utility. [6] The normal rules for bload apply (i.e. clear is automatically invoked before the file is bloaded). Due to the nature of bload you can only have one binary image file per screen. The format of this entry is :

    BinImage=filename

    For example, BinImage=c:\clips\examples\mab.bin

  6. PreserveFacts - This entry tells a screen whether or not to pass it's facts on for further processing. The format for this entry is :

    PreserveFacts=Cookie | Disk | Yes | No

    For example, PreserveFacts=yes

  7. SaveFactsFor - This entry works with 2 other entries :

    1. PreserveFacts=cookie
    2. CookieExpiration

    It contains the screen that the facts will be preserved for. This allows for saving facts between WebCLIPS sessions. Note : the screen can (and usually is) different than the current screen. The format for this entry is :

    SaveFactsFor=Screen name

    For example, SaveFactsFor=Battleship Screen

  8. CookieExpiration - This entry works with 2 other entries :

    1. PreserveFacts=cookie
    2. SaveFactsFor

    It determines how long to save a particular set of facts. There are two valid formats for this entry :

    1. To specify an absolute date use the following format :

      CookieExpiration=Date | standard cookie expiration format [7].

      For example, CookieExpiration=Date | Wednesday, 31-Dec-97 23:59:00 GMT

    2. To specify a relative amount of time use the following fomat :

      CookieExpiration=Days, Hours, Mins

    For example, CookieExpiration=1,1,30 would preserve a fact set for 1 day, 1 hour and 30 minutes.

    For more information, please refer to the section labelled How facts are passed.

  9. InitialScreen - This entry is the name of an HTML file that is displayed to the client. The format for this entry is :

    InitialScreen=filename

    For example, InitialScreen=c:\htmldocs\mab.htm

    For more information, please refer to the section labelled Static Screen User Interaction.

  10. LoadHelper - This entry tells a screen whether or not to load the HTML Helper Functions. The format for this entry is :

    LoadHelper=Yes | No

    For example, LoadHelper=yes

    Please note : in order to dynamically generate output screens from a CLIPS program this entry must be set to yes. For more information, please refer to the section labelled Using HTML Helper functions to generate screens in a CLIPS program.

  11. NextScreenName - This entry tell a screen what screen to process next. The format for this entry is :

    NextScreenName=Screen Name

    For example, NextScreenName=Monkey and Bananas Get monkey type

  12. AgendaLimit - This entry sets the limit for the number of rules to fire on ther Agenda. The format for this entry is :

    AgendaLimit=999 Please note that if -1 is specified, there is no Agenda limit.

  13. RouterList - This entry dictates which routers to open for a screen. Routers are separated by the pipe character '|'. The format for this entry is

    RouterList=router[| router2 | ... | routerN] This entry works in conjuction with the <router>Echo entry (see below). See the <routerEcho> section for an example.

  14. <router>Echo - This entry works with RouterList entry to re-route output from a CLIPS program. This entry dictates where the routed output should go. There are three valid options for this entry : no, screen and filename. If no is indicated or if this entry is missing, the router is ignored. If screen or filename is indicated then the output will be routed to the screen or to the filename. Please see the section Debugging CLIPS programs and re-routing output from CLIPS programs for more information. The format for this entry is :

    RouterList=wtrace|dribble
    wtraceEcho=screen
    dribbleEcho=c:\CLIPS\dribout.txt

Please note that when passing multiple parameters to a screen, the parameters are processed in numeric order (i.e. script1 is loaded first, followed by script2 etc.). If there is a break in the sequence, processing for this type of parameter will stop. For example, if a screen has entries for script1, script2, script3 and script5 only the first three scripts will be loaded.

Go to Table of Contents

Static vs Dynamic Mode

Parameters may be passed to a screen in 2 modes :

  1. Static mode -- Parameters that are listed in WebCLIPS.INI are used every time a screen is executed.
  2. Dynamic mode -- A screen can utilize facts from a previous screen to indicate which (and how many) parameters to use. These parameters are used in addition to any parameters listed in WebCLIPS.INI.

    There are four type of parameters that can be specified in this way :

    1. scripts - To tell the next screen to load a script called c:\rules\calcpay.clp, simply assert a fact that looks like this : (script c:\rules\calcpay.clp)

    2. factgroups - To tell the next screen to use a fact group (via load-facts) called c:\pumps\status.clp, simply assert a fact that looks like this : (factgroup c:\pumps\status.clp)

    3. ODBC queries - There are two type of ODBC queries with slightly different requirements :
      1. Embedded SQL - To tell the next screen to execute a query with the SQL embedded in the fact, assert a fact that looks like the following : 
        (odbcquery (query select * from MALE) (deftemplatename male) (connect DSN=CLIPSODBC;) (implodedata Y))

        The definition for the odbcquery deftemplate is loaded automatically and available to be used by any script (or binary image file) for this screen. This is how it is defined 

        (odbcquery (multislot query) (slot connect) (slot deftemplatename) (slot implodedata))

      2. SQL residing in an external file - To tell the next screen to execute a query with the SQL contained in an external file assert a fact that looks like the following : 
        (odbcqueryfile (file c:\SQL\males.txt) (deftemplatename male) (connect DSN=CLIPSODBC;) (implodedata Y))

        The definition for the odbcqueryfile deftemplate is loaded automatically and available to be used by any script (or binary image file) for this screen. This is how it is defined 

        (odbcqueryfile (slot file) (slot connect) (slot deftemplatename) (slot implodedata))

    4. a binary image file - To tell the next screen to bload a binary image file called c:\building\layout.bin, simply assert a fact that looks like this : (binimage c:\building\layout.bin)

Go to Table of Contents

Multi-Screen Navigation

WebCLIPS allows the development of multi-screen systems. Determining which screen will be processed next can be accomplished in two ways :

  1. Statically - One screen can unconditionally lead to another screen. This is done by using the 'NextScreenName' entry in WebCLIPS.INI

  2. Dynamically - The CLIPS program has two methods for telling WebCLIPS which screen to execute next :
    1. fact assertion - Assert a fact that looks like this :
      (assert (ScreenName (ScrnName Monkey and Bananas Demo Get Monkey Type)))

      The definition for the ScreenName deftemplate is loaded automatically and available to be used by any script (or binary image file) for this screen. This is how it is defined : 

      (deftemplate ScreenName (multislot ScrnName))

    2. HTML hidden data tag - By using the HTML Helper functions, you can pass the name of the next screen within an HTML document. For example, 
      (HiddenData "(ScreenName (ScrnName Monkey and Bananas Demo Get Monkey Type))")
Please note that if a fact is asserted or a screen-name is passed in a hidden data tag this will override the 'NextScreenName' entry in WebCLIPS.INI.

Go to Table of Contents

Static Screen User Interaction and passing data from HTML to CLIPS

Any standard HTML document can be used as an input screen to WebCLIPS. Data is sent from the HTML document to the web server by making the 'NAME' parameter of the tag 'fact' and the 'VALUE' parameter of the tag a standard fact in CLIPS format (i.e. <RHS pattern>+). For example, if you wanted to allow the client a choice of 'factgroup's for a screen, then the HTML could look like this : 

<FORM ACTION="/cgi-bin/WebCLIPS.EXE" METHOD="GET">

<INPUT TYPE="hidden" NAME="fact" VALUE="(ScreenName (Nuclear Reactor Monitor))">

<SELECT NAME="fact">

<OPTION VALUE="(factgroup c:\CA\pumpstat.clp)">Status of pumps in sector CA</OPTION>

<OPTION VALUE="(factgroup c:\WW\pumpstat.clp)">Status of pumps in sector WW</OPTION>

</SELECT>

<INPUT TYPE="submit">

</FORM>

This same mechanism can be used to assert facts to a CLIPS program. For example : 

<FORM ACTION="/cgi-bin/WebCLIPS.EXE" METHOD="POST">

<INPUT TYPE="hidden" NAME="fact" VALUE="(ScreenName (Wine Expert))">

<SELECT NAME="fact">

<OPTION VALUE="(WineType Red)">I would like a RED wine please</OPTION>

<OPTION VALUE="(WineType White)">I would like a WHITE wine please</OPTION>

</SELECT>

<INPUT TYPE="submit">

</FORM>
If the client selected 'I would like a WHITE wine please', this would cause a fact to be asserted that looked like this :
(WineType White)

In the case where the client is entering data into a textbox, textarea or password box, the HTML is a little more complicated. The 'NAME'/'VALUE' pair must be split up into two tags. One carries the name of the 'fact', the other carries the '<RHS pattern>+'. These tags are matched up inside of WebCLIPS and the fact asserted. For example : 

<FORM ACTION="/cgi-bin/WebCLIPS.EXE" METHOD="POST">

<INPUT TYPE="hidden" NAME="fact" VALUE="(ScreenName (Wine Expert))">

<INPUT TYPE="hidden" NAME="factname1" VALUE="ClientName">

<INPUT TYPE="hidden" NAME="factname2" VALUE="WineName">

Hello, what is your name?

<INPUT TYPE="text" NAME="factvalue1" size=40>

What is your favorite wine?

<INPUT TYPE="text" NAME="factvalue2" size=40>

<INPUT TYPE="submit">

</FORM>
If the client entered 'Garry Kasparov' in the ClientName box and 'Merlo' in the WineName box, then the following facts would be asserted into the CLIPS program : 
(ClientName Garry Kasparov)

(WineName Merlo)

Go to Table of Contents

Using HTML Helper functions to generate screens in a CLIPS program

You do NOT need to know HTML in order to properly output data from WebCLIPS (although it is strongly recommended). The Helper functions insulate the developer from knowing all of the nuances of HTML. A good working knowledge of some of parameters to certain HTML tags may be required.

In order to use the HTML Helper functions in WebCLIPS, you must add the following 2 lines of code to your CLIPS programs : 

(defmodule MAIN (import WebCLIPSHTML deffunction ?ALL)

                (import WebCLIPSTemplates deftemplate ?ALL))
All HTML from the Helper functions are standard to version 3.2

Given below is a list of all HTML Helper functions available :

HTMLHeader (?title)BodyTag ($?bodyargs)
HeadStart ($?dummy) HeadEnd ($?dummy)
HeadStartTag ($?dummy) HeadEndTag ($?dummy)
ScriptStart (?lang) ScriptEnd ($?dummy)
ScriptStartTag (?lang) ScriptEndTag ($?dummy)
JavaScriptStart ($?dummy) JavaScriptEnd ($?dummy)
JavaScriptStartTag ($?dummy) JavaScriptEndTag ($?dummy)
VBScriptStart ($?dummy) VBScriptEnd ($?dummy)
VBScriptStartTag ($?dummy) VBScriptEndTag ($?dummy)
Base (?URL) BaseTag (?URL)
Link (?URL) LinkTag (?URL)
Break ($?arg) BreakTag ($?dummy)
Paragraph ($?align) ParagraphStartTag ($?align)
ParagraphEndTag ($?dummy) IsIndex ($?dummy)
IsIndexTag ($?dummy) Applet (?prog ?width ?height $?args)
AppletParm ($?args) SSI (?SSIType ?URL $?args)
Image (?URL $?args) ImageTag (?URL $?args)
FormStart (?exec $?method) FormEnd ($?dummy)
FormStartTag ($?dummy) FormEndTag ($?dummy)
SelectStart (?varname $?args) SelectEnd ($?dummy)
SelectStartTag (?varname $?args) SelectEndTag ($?dummy)
DropDownStart (?varname) DropDownStartTag (?varname)
DropDownEnd ($?dummy) DropDownEndTag ($?dummy)
ListBoxStart (?varname ?NumElems) ListBoxStartTag (?varname ?NumElems)
ListBoxEnd ($?dummy) ListBoxEndTag ($?dummy)
Option (?value $?args) SubmitButton ($?caption)
ResetButton ($?caption) HiddenData ($?factvalue)
TextArea (?rows ?cols $?text) TextAreaStartTag ($?args)
TextAreaEndTag ($?args) TextBox (?name ?size $?maxlength)
TextBoxTag (?name ?size $?maxlength) PasswordBox (?name ?size $?maxlength)
PasswordBoxTag (?name ?size $?maxlength) TextAreaBox (?name ?size ?maxlength)
TextAreaBoxTag (?name ?size ?maxlength) RadioButton (?name ?text $?args)
RadioButtonTag (?name ?text $?args) CheckBox (?name ?text $?args)
CheckBoxTag (?name ?text $?args) ImageButton (?name ?URL $?args)
ImageButtonTag (?name ?URL $?args) Anchor (?URL ?LinkText)
AnchorInternal (?IRL ?LinkText) AnchorReference (?IRL ?LinkText)
ul ($?args) ULStartTag ($?args)
ULEndTag ($?args) ol ($?args)
OLStartTag ($?args) OLEndTag ($?args)
dir ($?args) DirectoryStartTag ($?args)
DirectoryEndTag ($?args) Menu ($?args)
MenuStartTag ($?args) MenuEndTag ($?args)
li ($?args) hr ($?args)
h1 (?title $?args) h2 (?title $?args)
h3 (?title $?args) h4 (?title $?args)
h5 (?title $?args) h6 (?title $?args)
TableStart ($?args) TableStartTag ($?args)
TableEnd ($?dummy) Caption (?text $?args)
CaptionStartTag ($?args) CaptionEndTag ($?args)
TableHeader ($?args) TableHeaderStartTag ($?args)
TableHeaderEndTag ($?args) TableRow ($?args)
TableRowStartTag ($?args) TableRowEndTag ($?args)
TableDataStartTag ($?args) TableDataEndTag ($?args)
Address (?text) AddressStartTag ($?dummy)
AddressEndTag ($?dummy) Big (?text)
BigStartTag ($?dummy) BigEndTag ($?dummy)
BlockQuote ($?text) BlockQuoteStartTag ($?dummy)
BlockQuoteEndTag ($?dummy) Bold ($?text)
BoldStartTag ($?dummy) BoldEndTag ($?dummy)
Center ($?text) CenterStartTag ($?dummy)
CenterEndTag ($?dummy) Cite ($?text)
CiteStartTag ($?dummy) CiteEndTag ($?dummy)
Code ($?text) CodeStartTag ($?dummy)
CodeEndTag ($?dummy) DefStartTag ($?args)
DefList ($?args) DefListStartTag ($?args)
DefListEndTag ($?args) DefTermTag ($?args)
Emphasize (?text) EmphasizeStartTag ($?dummy)
EmphasizeEndTag ($?dummy) Font (?text $?args)
FontStartTag ($?args) FontEndTag ($?args)
Italics (?text) ItalicsStartTag ($?dummy)
ItalicsEndTag ($?dummy) Keyboard (?text $?args)
KeyboardStartTag ($?dummy) KeyboardEndTag ($?dummy)
Pre (?text $?args) PreStartTag ($?args)
PreEndTag ($?args) Sample (?text)
SampleStartTag ($?dummy) SampleEndTag ($?dummy)
Small (?text) SmallStartTag ($?dummy)
SmallEndTag ($?dummy) Span (?text $?args)
SpanStartTag ($?args) SpanEndTag ($?args)
StrikeThru (?text) StrikeThruStartTag ($?dummy)
StrikeThruEndTag ($?dummy) Strong (?text)
StrongStartTag ($?dummy) StrongEndTag ($?dummy)
Subscript (?text) SubscriptStartTag ($?dummy)
SubscriptEndTag ($?dummy) Superscript (?text)
SuperscriptStartTag ($?dummy) SuperscriptEndTag ($?dummy)
Teletype (?text) TeletypeStartTag ($?dummy)
TeletypeEndTag ($?dummy) Underline (?text)
UnderlineStartTag ($?dummy) UnderlineEndTag ($?dummy)
Var (?text) VarStartTag ($?dummy)
VarEndTag ($?dummy)

Some sample CLIPS code to utilize some of these functions : 

(defrule setup "print out HTML header tags and body tags"

=>

(HTMLHeader "Water Quality Expert")

(BodyTag bgcolor=#COCOCO alink=#FF0000 vlink=#00FF00)

(h3 "Water Quality Expert System" align=center)

(hr)

(TableStart cellpadding=3 border=3)

(assert (func ListGoodTowns)))



(defrule GoodWaterTowns "show towns with good water quality"

   (Town (Quality Good) (Name ?nm))

   ?rn <- (func ListGoodTowns)

=>

(TableRow Good ?nm))



(defrule setupBadWaterTowns "Start printing bad water towns"

   ?rn <- (func ListGoodTowns)

=>

(retract ?rn)



(assert (func ListBadTowns)))



(defrule BadWaterTowns "show towns with bad water quality"

   (Town (Quality Bad) (Name ?nm))

   ?rn <- (func ListBadTowns)

=>

(TableRow Bad ?nm))



(defrule HTMLCleanUp "Ending tags"

   ?rn <- (func ListBadTowns)

=>

(TableEnd)

(Break)

(RadioButton fact "Value=(Contact Mayor)" Checked) ;Display two radio buttons asserting a fact about who to contact

(Break)

(RadioButton fact "Value=(Contact Commisioner)" ))

How facts are passed

After a CLIPS program has finished running, WebCLIPS checks to see if the screen wants to save it's facts for another screen. It does this by checking the PreserveFacts entry. There are two ways to accomplish this :

  1. If PreserveFacts=yes, then ALL visible facts from the CLIPS run are saved as HTML 'hidden' data tags. This is an expensive operation and only those facts essential for future processing should be passed.

  2. If PreserveFacts=disk, then ALL visible facts from the CLIPS run are saved to a file on disk. The name of the file is passed as a <hidden> tag and used by the next program. This does present the system administrator with a small task. Please see the section Administration issues for more details.

  3. If PreserveFacts=cookie, then ALL visible facts from the CLIPS run are saved to a file on disk. The name of the file is placed in an HTTP cookie and used by the program specified in the SaveFactsFor entry. For example : 
    
[Battleship Setup Screen]

PreserveFacts=cookie

SaveFactsFor=Play BattleShip

NextScreenName=Play BattleShip

CookieExpiration=1,1,30

script1=c:\clips\examples\btlshpsu.clp

.

.

.



[Play BattleShip]

script1=c:\clips\examples\batlship.clp

.

.

.
    In this setup, the screen 'Battleship Setup Screen' will save all visible facts to a disk file and store
    Play BattleShip=file name in a cookie. The next time the screen 'Play BattleShip' is run, it will look to see if there is a file containing facts to be loaded (via the load-facts command).

    This does present the system administrator with a small task. Please see the section Administration issues for more details.

Go to Table of Contents

Debugging CLIPS programs and re-routing output from CLIPS programs

Traditionally, a CLIPS programmer would issue a (watch facts) or (watch rules) to see facts being retracted and rules being fired. The developer would issue a dribble command (for example) and the results could then be reviewed. This can be accomplished by using (for a screen) RouterList and <router>Echo entries as follows :

[Monkey and Bananas Demo]
RouterList=dribble
dribbleEcho=c:\CLIPS\testing\pgmdrib.txt

This would have the effect of placing all output from dribble to the file c:\CLIPS\testing\pgmdrib.txt.

For those who would like to see facts being asserted/retracted and rules being fired to the screen, put a (watch facts) and a (watch rules) into the CLIPS program and set up the following two entries (for a screen) in WebCLIPS.INI :

[BattleShip]
RouterList=wtrace
wtraceEcho=screen

Some sample output could look like :

wtrace

FIRE    2 HumanGuessNo: f-48,f-47

<== f-48    (Phase LookForSquare)

==> f-49    (Phase LookForHit)

==> f-50    (AlreadyGuessed (Player Human) (XY A1))

==> f-51    (CheckPlayer Computer)

FIRE    3 MissShip: f-49,f-51,f-47,f-5,,f-1,f-2

<== f-5     (Grid (Player Computer) (XY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .))

==> f-52    (Grid (Player Computer) (XY X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .))

<== f-51    (CheckPlayer Computer)

<== f-49    (Phase LookForHit)

<== f-47    (Guess A1)

==> f-53    (Phase MakeGuess)

==> f-54    (CheckPlayer Human)

FIRE    4 GenerateGuess: f-53,f-1,f-2

==> f-55    (Guess J2)

<== f-53    (Phase MakeGuess)

==> f-56    (Phase CheckGuess)

FIRE    5 LookForShip: f-56,f-55

<== f-56    (Phase CheckGuess)

==> f-57    (Phase LookForHit)

==> f-58    (AlreadyGuessed (Player Computer) (XY J2))

FIRE    6 MissShip: f-57,f-54,f-55,f-30,,f-1,f-2

<== f-30    (Grid (Player Human) (XY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . S S S C C C C C . . . . . . . . . . . . . . . . . . . . . . . . . B . . . . . . . . . B . . . . . . . . . B . R R . . . . . . B . . . .))

==> f-59    (Grid (Player Human) (XY . . . . . . . . . . . . . . . . . . . X . . . . . . . . . . . . S S S C C C C C . . . . . . . . . . . . . . . . . . . . . . . . . B . . . . . . . . . B . . . . . . . . . B . R R . . . . . . B . . . .))

<== f-54    (CheckPlayer Human)

<== f-57    (Phase LookForHit)

<== f-55    (Guess J2)

==> f-60    (Phase PaintScreenHeader)

FIRE    7 PainttheScreen: f-60,f-1,f-2

<== f-60    (Phase PaintScreenHeader)

==> f-61    (Phase PaintHumanGrid)

FIRE    8 PaintHumanBoard: f-61,f-1,f-2,f-59,f-6

<== f-61    (Phase PaintHumanGrid)

==> f-62    (Phase PaintCompGrid)

FIRE    9 PaintCompBoard: f-62,f-1,f-2,f-52,f-7

<== f-62    (Phase PaintCompGrid)

==> f-63    (Phase PaintStatus)

FIRE   10 PaintStatusArea: f-63,f-1,f-2

<== f-63    (Phase PaintStatus)

==> f-64    (Phase CleanUp)

FIRE   11 EliminateCoords: f-64,f-2

<== f-2     (CoordsTable (Axis Y) (coord 1 2 3 4 5 6 7 8 9 10))

FIRE   12 EliminateCoords: f-64,f-1

<== f-1     (CoordsTable (Axis X) (coord A B C D E F G H I J))

FIRE   13 UpdateFinalPhase: f-64

<== f-64    (Phase CleanUp)

==> f-65    (Phase SetupGuess)

Output from user-defined routers is also available. They are handled in exactly the same manner as any other router in WebCLIPS.INI. The only real difference is the (printout ... ....) statements in your program. For example :

RouterList=clpout|wtrace
clpoutEcho=screen
wtraceEcho=c:\debug\result.txt

Now in your program include : (printout clpout "Hello world" crlf) and the results will show follows :

clpout


Hello World

There are certain routers that cannot be echoed using the screen option. These are :

Go to Table of Contents

Administration Issues

There are several administration issues to be addressed when setting up WebCLIPS.

Go to Table of Contents

Reserved fact and deftemplate names

The following is a list of reserved names for use by WebCLIPS

Fact NamesDeftemplate Names
binimageodbcquery
factgroupodbcqueryfile
scriptScreenName

These are the definitions of the deftemplates as used by WebCLIPS : 

(deftemplate ScreenName (multislot ScrnName))



(deftemplate odbcquery     (multislot query) (slot connect)

                           (slot deftemplatename) (slot implodedata))



(deftemplate odbcqueryfile (slot file)       (slot connect)

                           (slot deftemplatename) (slot implodedata))

Go to Table of Contents

References
#SiteInternet Address
[1]CLIPS Home Pagehttp://www.ghgcorp.com/clips/CLIPS.html
[2]Microsoft Home Pagehttp://www.microsoft.com
[3]CLIPS DLL Home Pagehttp://ourworld.compuserve.com/homepages/marktoml/clipstuf.htm
[4]HTML Primerhttp://www.ncsa.uiuc.edu/General/Internet/WWW/HTMLPrimer.html
[5]CLIPS/ODBC Interfacehttp://www.monmouth.com/~km2580/CLIPODBC.htm
[6]WebCLIPS BSave utilityhttp://clipsinterface.sourceforge.net/WebCLIPS/wcbsave.htm
[7]Cookie Expiration Formathttp://home.netscape.com/newsref/std/cookie_spec.html"

Go to Table of Contents

Last modified : 28-Jul-2003
Michael Giordano