The ClassID of the panel Publications and its objects is 9.

The ClassID of the panel Publication Info and is 19.

The current state of the document is shown in the first column of the publication list.

The following states are defined:

One row of the Publications list contains the following information:

The yellow numbers correspond to the result columns after the record ID of the panel statements 36 (XML) resp. 37 (ODBC), which are used to load the list entries.

The following values are shown in the Publication Information:

The yellow numbers correspond to the result columns after the record ID of the panel statements 36 (XML) resp. 37 (ODBC), which are used to load the list entries.

You can use the following statements for XML data. You can find example data files that work with these statements here.

Panel statement 36 in XML

<panelstatement>
   <id>36</id>
   <usage></usage>
   <domain>Load the documents according to the search data in the panel
   </domain>
   <statement>
      "documents.xml"
      select
         id, 0, 0, ""                  <!-- entry ID -->
         name,                         <!-- (1) -->
         info,                         <!-- (2) -->
         "in progress",                <!-- (3) -->
         info2,                        <!-- (4) -->
         info3,                        <!-- (5) -->
         domainname,                   <!-- (6) -->
         title,                        <!-- (7) -->
         path,                         <!-- (8) -->
         url,                          <!-- (9)  Mac OSX only, ignored in Windows! -->
         canoverrideurl,               <!-- (10) -->
         canoverridelocal,             <!-- (11) 0 or 1, add 2 to this value to hide the download button -->
         subStatementID,               <!-- (13) optional load sub entries -->
         iconID                        <!-- (13) optional entry icon, see below -->
      node documents.document
      where 	id &gt; ?
            and	(domainid = ? or 0 = ?)
            $1 $2 $3                    <!-- Search parameter, see below -->
   </statement>
   <in_parameters></in_parameters>
   <out_parameters></out_parameters>
   <description></description>
</panelstatement>

In SOAP environment, "getList" is called to find and load list entries, a corresponding panel statement (36) may look somewhat like what's shown here here. As of R1145 (February 2009) you can use a "normal" XML Queryfor this, as you would in XML environments (see above).

As of R1145 (Feb. 2009) panel statement 36 in SOAP may contain a "normal" XML Query, too. Both query types may be used, getList and XML-Query; the distinction is made based on the first term is a string in quotes (file for XML Query) or not (SOAP call).

Panel statement 36 in SOAP

getlist 
	sql
	SELECT 
		id,0,0,"",		-- id1 .. 3
		name, 
		status,
		docinfo,
		market,
		info1,
		info2,
		domain,
		path,
		url,
		canoverrideurl,
		canoverridelocal,
		IF( hasChildren >0, 20000, 0), 	-- subtree
		2007							-- icon id
	FROM `publication`
	WHERE parent =0

Panel statement 37 in XML and SOAP

<!-- This statement is unneeded -->

Panelstatement 38 in XML and SOAP

<panelstatement>
   <id>38</id>
   <usage></usage>
   <domain>Load the publication domains
   </domain>
   <statement>
      "documents.xml"
      select domainid, domainname
      node documents.document
   </statement>
   <in_parameters></in_parameters>
   <out_parameters></out_parameters>
   <description></description>
</panelstatement>

Some examples follow, showcasing correct panel statements for SQL to fill the panel.

If you want to use custom panel statements, make sure that the number and data types of ? in the statements are correct.

Panel statements 36 in SQL

rem
rem 36 : Load the list IDs
rem
delete from PanelStatements where ID = 36;
insert into PanelStatements values (
  36,
  '',
  'Load the IDs of the list of documents',
  'select ID, 0, 0, ""
    from Documents
    where ID > ?                  -- Replaced with 0 (int)
      and (DomainID = ? or 0 = ?) -- ID of the selected domain (int)
      and rownum < ?              -- Replaced with 400 (int)
      and platform = ?            -- 1 (Windows), 2 (Mac)
      $1 $2 $3',                  -- Search Parameters, see below
   '',
   '');

Panel statement 37 in SQL

rem
rem 37 : Load the list entries
rem
delete from PanelStatements where ID = 37;
insert into PanelStatements values (
   37,
   '',
   'Load a document into the list',
   'select
         d.name,                  -- (1)
         ''Marketname'',           -- (2)
         ''Status'',              -- (3)
         ''Info 1'',      		-- (4)
         ''Info 2'',      		-- (5)
         p.name,                  -- (6)
         ''Documentinfo'',        -- (7)
         d.path,                  -- (8)
         d.url,                   -- (9)  
         d.canOverrideURL,        -- (10) 0 or 1
         d.canOverrideLocal,      -- (11) 0 or 1, add 2 to this value to hide the download button 
         subStatementID,          -- (12) optional load sub entries
         iconID                   -- (13) optional entry icon
      from documents d, domain p
      where d.id = ?              -- Document ID
         and p.id = d.domainid',
   '',
   '');

Panel statements 38 in SQL

rem
rem 38 : Load the domains
rem
delete from PanelStatements where ID = 38;
insert into PanelStatements values (
   38,
   '',
   'Load all domains',
   'select distinct (d.id), d.name
      from domain d, userxdomain x
      where 		d.ID > 0
         and 	(x.userid=? or 0=?)  -- User ID (int)
         and 	d.id = x.domainid',
   '',
   '');

commit;

As of R678, statements 36 and the sub entry load statements support StringIDs. To make use of this, the file panelstatements.xml, and the table panelstatements have to support StringIDs as well:

<panelstatement>
   <id>36</id>
   <usage></usage>
   <domain>Load the documents according to the search data in the panel
   </domain>
   <statement>
		...
   </statement>
   <in_parameters></in_parameters>
   <out_parameters></out_parameters>
   <description></description>
   <hasstringids>1</hasstringids>
</panelstatement>

This changes the order of result columns as follows:

The 4th value (after the 3 numerical IDs) is expected to be the StringID, all following column indices are thus incremented by 1.

In addition to the panel-specific default tags, a number of tags are defined for the panel, which allow access to the values of publications. In the scripting language, the same names are used to access the values of publications. The following table lists the special tags defined for the Publikationen panel. Tge tags are referred to as <TagName>, as usual, and replaced by their current values at run time. String values are automatically surrounded with quotes. Quotes in the values are masked differently, depending on the platform. Tagnames are case sensitive.

To access values of parent entries in a tree view, you can prepend one or more "parent." to tagnames. If the corresponding predecessor generation is inaccessible, their values are replaced by empty strings or 0, respectively.

For example, this gets the grandparent's name. For entries in layers 0 and 1, the returned value is empty ('').

<parent.parent.Name>

The values of tags with strings are automatically surrounded with single quotes. Single quotes inside the string are doubled. To prevent this behaviour, you can prefix the tags.

The old designator StringID (in this spelling) is not surrounded with quotes.

Please note that the prefixes Unquoted_ and Content_ are always inserted before the last word of a tag!

The entries in the panel can be viewed in a tree structure. To get a tree view, the statements that load the list (36 in SOAP and XML, 37 in SQL) have to have the parameters subStatementID and iconID. If an entry has subentries, subStatementID refers to a panel statement that loads such entries. If an entry does not have any subentries, subStatementID is empty (=0). The IconID determines which icon will be displayed with the entry in the panel.

The parameters are optional, but if you specify one, you also have to specify the other.

The subStatementID refers to a panel statement which loads subentries of a publication, otherwise it's 0. Choose a free ID greater than 10,000 in panelstatements[.xml]. This statement should return the three IDs of a subentry. After the three IDs, the same parameters follow, as in the superior statement 36 in SOAP and XML, or 37 in SQL. However, subStatementID and iconID are not optional here. If you reached the end of the tree, the subStatementID becomes 0, otherwise it will be assigned another free panelstatement ID.

Panel statement 10000+x for loading subentries in SQL. The statement loads the publications again as their own subtag, etc..

rem
rem 10200 : Load list entries
rem
delete from PanelStatements where ID = 10200;
insert into PanelStatements values (
    10200,
    '',
    'Load a document into the list',
    'select
          id, 0, 0,
          d.name,                  -- (1)
          ''Marketname'',           -- (2)
         ''Status'',              -- (3)
         ''Info 1'',      -- (4)
         ''Info 2'',      -- (5)
         p.name,                  -- (6)
          ''Documentinfo'',        -- (7)
         d.path,                  -- (8)
         d.url,                   -- (9)
          d.canOverrideURL,        -- (10) Mac OSX only, ignored in Windows!
          d.canOverrideLocal,      -- (11)
          10200,                   -- (12)
          2012                     -- (13)
       from documents d, domain p
       where d.id = <parent.ID>',
    '',
    '');

Panel statement 10000+x for loading subentries in XML and SOAP. The statement loads the publications again as their own subtags, etc..

<panelstatement>
    <id>102000</id>
    <usage>Load document subentries</usage>
    <domain></domain>
    <statement>
        "documents.xml"
        select
            id, 0, 0,
            name,               <!-- (1)  -->
            title,              <!-- (2)  -->
            info2,              <!-- (3)  -->
            info3,              <!-- (4)  -->
            "",                 <!-- (5)  -->
            "",                 <!-- (6)  -->
            domainname,         <!-- (7)  -->
            path,               <!-- (8)  -->
            url,                <!-- (9)   Mac OSX only, ignored in Windows! -->
            canoverrideurl,     <!-- (10) -->
            canoverridelocal,   <!-- (11) -->
            10200,              <!-- (12) -->
            2012                <!-- (13) -->
       node documents.document
       where 		id = &lt;parent.ID&gt
    </statement>
    <in_parameters>int</in_parameters>
    <out_parameters>string</out_parameters>
    <description></description>
    <hasstringids>0</hasstringids>
</panelstatement>

In the publications all defined Comet icons can be used.

After performing the required panel installations, you can tweak the search to your personal needs.

When the search is triggered (), the menues are interpreted as follows :

1. Behind every menu entry lies a piece of SQL, containing two ?. In place of the ?, the text of the corresponding search text field is inserted. If the menu requires a string value, the search text is converted to upper case and surrounded with quotes.
   If the search text field is empty, an empty string is used - i.e. the field is unused in the query.
2. The menues themselves correspond to a keyword. The keyword is found in panelstatement 36 and replaced with the text from step one.

Sounds complicated? An example for the first menu follows:

In the first step, we define a menu. (Menu entries are defined in the second step). In the current version, only the ID, the key and a default value are important to a menu. The default value determines, which menu entry should be selected on start up. Just count the menu entries for that (ordered by their AequenceNr..).

insert into ConditionMenues (
   ID,
   Description,
   Label,
   Keyword,
   DefaultSelection)
values (
   1,
   'Search key 1 in the "Documents" panel',
   '',
   '$1',  -- Replace $1 in panelstatement 36
   6);    -- 6th menu entry selected by default

In the second step, we define individual menu entries. For each entry, assign a unique ID, a name (visible in the panel), a search value and the data type. The value ReplaceByValue is unused at the moment. The first entry:

insert into Conditions (
   ID,
   ConditionMenueID,
   SequenceNr,
   Label,
   Value,
   TypeID,
   ReplaceByValue)
values (
   1,
   1,       -- menu entry with ID 1
   1,
   'Order Number',
   'and (upper(name) like  ? || ''%'' or '''' = ?)',
   3,       -- 1=int, 2=float, 3=String
   0);

List entries can respond to double clicks. The action executed on double click on a row is also executed on successful download / opening () of the entry. The two contexts differ in that the global script document is not set after a double click :

if (document::is_valid (gDocument))
{
	// Download/Open
}
else
{
	// Double click
}

The action is defined as follows :

1. With panelstatement 96 a product is assigned an integer action ID. The statement can take up to three input values (int, int, int), which will be replaced with current document ID. Furthermore, the general standard tags, such as <ID>, <ID2>, <folder>, ..., are defined. An entry's parent properties can be accessed with the parent tags of the publication panel. You can access the entry's own properties (only during loading of the double click action) with tags without the <parent. prefix - e.g. just <Info1>.
2. If a double click action is defined (>0), the action is executed as a script. Within the script, an additional global variable gClicked is defined, which contains the 0-based line number of the entry.
   
   As of R1110, you can also access line contents from a script : Whereever you need such a value, just write the corresponding tag - it will be replaced before execution : for example
   
       showmessage ("<Name>, <DokumentInfo>, <parent.DokumentInfo>");

Some examples for valid panel statements defining double click IDs follow.

Each nesting layer has its own double click script (SQL)

select 900+<depth> from dual;      

Each nesting layer has its own double click script (XML). In place of dual, use any existing XML file.

"datafiles.xml"                        
select 900+<depth>    

This double click action does not work weekends

select IF(<dayOfWeek><5,1,0) from dual  

Up to three question marks may be used in the statement. They are replaced by the current ID of the publication. The following two statements are equivalent

select id%3 from ... where ID = ?       
select id%3 from ... where ID = <ID>   -- The ? are optional

Here's a simple double click script that displays some information about the clicked row. If the script was triggered by a double click, it is returned from afterwards. If the script was triggered by a download / open button, the document ID1 is incremented by 1.

int main ()
{
    int  id = 0;

    showmessage ("Row %d : %d (%s of %s of %s)",
        	gClicked+1,
        	gRecordID,
        	"<Name>",
        	"<DocumentInfo>",
        	"<parent.DocumentInfo>");
	
    // Finish script in case of a double click
    //
   if (!document::is_valid (gDocument)) return 0;

    document::getid (gDocument, &id);
    showmessage ("Document-ID = %d", id);
    document::setid (gDocument, id+1);

    return 0;
}

As of R1818 / Comet 3.1 the panel supports some more panel statements and mechanisms for document state management. The main use case is integration of the desktop plugins with a priint:cometserver environment, however, the extensions can also be used for normal ODBC and SOAP connections.

The extensions are activated if the panel statement 114 (Document Status) .

The connection to the priint:cometserver is established if the panelstatement 110 (connection data) is defined and non-empty.

Panelstatement 110: Load connection data for priint:cometserver. Return values expected in the following order:

1. endpoint
2. user
3. password
4. dataset (client)
5. language
6. serverendpoint (optional)

The 6th column (serverendpoint) allows defining an alternative service endpoint for InDesign® Server. The reasoning being that InDesign® Server is commonly found in another network environment and can access the priint:cometserver by an internal address / IP.

The following placeholders are replaced in the statement from the current data connection:

• <user>
• <password>
• <client>
• <dbname>
• <language>
• <server>
• <host> (Programm environment, InDesign® Server resp. InDesign®)
• <os.user> (Login user nname)
• <os.host>
• <os.ip>
• <os> (Replaced by Mac resp. Windows)

Here's an example.

SELECT
    'http://demo.priint.com/CometServerSOAP/CometPriintService',
    '<user>',
    '<password>',
    '<client>',
    '<language>'

Panelstatement 111 : Checkout a document. Only cScript is expected and supported here. Please note the tips on the Script Environment below.

The script is executed before the document is opened and should make necessary preparation (setting states, downloading data, etc..). If the script returns anything != 0, the freeing script (panelstatement 117) is called (if it is defined) and no local status (checked out) is saved. This allows client side errors to be handled and the server (priint:cometserver or another publication system) to be notified of the failure.

You can use the same tags as in a double click script, for more information on the script environment, see below. If the document path changes due to the script, the new path has to be copied into the global variable gDocumentPath.

int main ()
{    
	char * path = alloc (4096);

	// Request the document from the server.
    // priint::checkout requires an established connection to a priint:cometserver.
    // The document may not be available locally and has to be downlaoded via SOAP.
    // After successful checkout, the return variable path contains the real path to
    // the document - either the original on a file server, or a temporary working
    // copy in the local file system.    
    //
    int result = priint::checkout ("<Content_StringID>", path);

    if (result == 0)
    {        
    	strcpy (gDocumentPath, path);    
    }    
    else
    {        
    	wlog ("", "checkout <Name> (<StringID>) failed with result code %d\n", result); 
    }
    
    release (path);    
    
    return result;
}

Using panelstatement 111 deactivates the "normal" behaviour (automatic download, duplication of model documents etc.). Regardless, the double click script is run after successful script execution or opening the document.

Panelstatement 112: After Save Script. Only cScript is expected and supported here. Please note the tips on the Script Environment below.

This script is executed after saving a document opened from the publication panel. You can use the same tags as in a Double Click Script (regardless of the object's visibility when saving). If you do not need to react to save events, you can leave this panelstatement empty or undefined.

Here's an example.

int main ()
{
    wtlog ("", "Still working on <Content_Name> (<Content_StringID>) ...\n");
    
    return 0;
}

Panelstatement 113: Before Close Skript. Only cScript is expected and supported here. Please note the tips on the Script Environment below.

This script is run before a document opened from the publication panel is closed. You can use the same tags as in a Double Click Script (regardless of the object's visibility when saving). If you do not need to react to close events, you can leave this panelstatement empty or undefined.

Here's an example.

int main ()
{
    // This script uploads the document's meta data  
    // to the server before closing (Spreads, Groups, Placeholders, Notes ...)
    // Note that this may not be the ideal place to do this - a more sensible
    // approach may be doing so in panelstatenebt 115 (on explicit checkin)
	//
	return priint::upload_metadata ("<Content_StringID>", gDocumentPath);
}

Please note : Panelstatement 113 is also executed, when a publication document is closed by checkin (by button click, the menu command, or a call to the priint:call_checkin function) - unless, priint::call_checkin got called from within the script itself.

With the following example, documents can be automatically checked in when closing:

int main ()
{
	return priint::call_checkin ("<Content_StringID>", gDocumentPath);
}

Panelstatement 114: Status Script. Only cScript is expected and supported here. Please note the tips on the Script Environment below.

This script is executed for each object in the panel with a visible "Opener" button. It should determine the state of a document on the publication server or the database. The value has to be copied into the global variable gDocumentStatus. The following values are valid (defined in "internal/types.h"):

• kAvailable (1): The document is available and may be used
• kOpenedOnServer (2): The document is opened on the priint:cometserver and may not be used at the moment
• kOpenedOnClient (3): The document is opened on another client and may not be used at the moment
• kOpenedByUser (4): The document is opened by the current user. If it should not be used in this case, the status should be set to kOpenedOnClient instead
• kOpenedInSession (5): The document is opened in the current session
• kNotExisting (6): The document does not exist (a model document may have to be generated first)
• kNotRegistered (7): The document is not registered and may not be used.

Here's an example.

int main ()
{
    int 	status = priint::document_status ("<Content_StringID>");    
    
    if (status >= 0)
    {        
    	*gDocumentStatus = status;    
	}
	else
	{
		wlog ("", "document <Name> (<Content_StringID>) status could not be obtained: %d\n", status);
		return -1;
	}
	
	return 0;
}

Panelstatement 115: Checkin script. Only cScript is expected and supported here. Please note the tips on the Script Environment below.

The script is run when the checkin button is clicked or the menu entry "Checkin all documents" is selected. On success, the document is closed (if it was opened).

Here's an example.

int main ()
{
    int 		result = priint::checkin ("<Content_StringID>", gDocumentPath);
    
    if (result != 0)
    {        
    	wlog ("", "checkin <Name> (<Content_StringID>) failed with result %d\n", result);    
    }   
    
    return result;
}

Panelstatement 116: After Close script. Only cScript is expected and supported here. Please note the tips on the Script Environment below.

The script is executed after a publication document is closed.

Here's an example.

int main ()
{
    int 		result = priint::checkin ("<Content_StringID>", gDocumentPath);
    
    if (result != 0)
    {
        wlog ("", "checkin <Name> (<Content_StringID>) failed with result %d\n", result);
    }
    
    return result;
}

Panelstatement 117: Revert Document script. Only cScript is expected and supported here. Please note the tips on the Script Environment below.

This scipt is executed if checkout (panelstatement 111) fails or either the menu entry Free Document or Free All Checked-Out Documents is selected, or the checkin button is clicked while the shift and alt keys are held down.

Here's an example.

int main ()
{
    int 		result = priint::revert ("<Content_StringID>", gDocumentPath);
    
    if (result != 0)
    {
        wlog ("", "revert <Name> (<Content_StringID>) failed with result %d\n", result);
    }
    
    return result;
}

This script is executed after successful checkout or a publication document is opened (for the first time). The document can be accessed with the global variable gDocument. Typically, this script sets document specific attributes.

Here's an example.

int main ()
{
    int 		result = xml::set_document_attribute(gDocument, "documentId", gDocumentID);
    
     return result;
}

Panelstatement 135: Options for meta data generation. Only SQL and SOAP statements are expected and supported here. If this panelstatement is empty or undefiend, the default setting (content:none;svg:bbox;), or a value passed to priint::checkin as a parameter is used.

With these options, the output format adjusted to project specific requirements - without changing the call to the priint::checkin function (usually found in panelstatement 115).For valid values, see Options.

SOAP Statement for generating "raw" TaggedText content, no SVG coordinated specified:

BOUNCE 'content:raw;svg:none;'

Panelstatement 136: Meta data files to be generated. Only SQL and SOAP statements are expected and supported here. If this panelstatement is empty or undefined, a meta data set depending on the env parameter of the priint::checkin function is generated:

• env = kNoInDesingServer: generate full data set
• env = kWithInDesignServer : only generate Comet Notes

A list of all requested formats is expected as a return value. The valid (case insensitive) values are

• Spreads
• Groups
• Placeholders
• Elements
• Items
• Previews

Here's an example.

SELECT formatname FROM metadataformat WHERE active = 1;

In publication scripts, a number of global variables are available:

// Index of the current record in the current list on the panel
//
int 	gClicked;

// ID of the record
//
int 	gRecordID;

// ID2 and 3 of the record
//
int 	gRecordID2;
int 	gRecordID3;

// StringID1, 2, 3 of the record
//
char 	gRecordStringID[];
char 	gRecordStringID1[];
char 	gRecordStringID2[];
char 	gRecordStringID3[];

// Save path of the document, may differ from the path provided by the server, if the
// document had to be downloaded. In Panelstatement 111 the actual path (e.g. provided
// by the command priint::checkout) has to be copied into this variable
//
char * 	gDocumentPath;

// Status of the document. In Panelstatement 114, this variable has to be set to the correct value 
// 
int *  	gDocumentStatus;

// Path or ID of the document template
//
char 	gMasterDoc [];

// documentID (see below). This variable is not available in the checkout script
// (Panelstatement 111), because it is not yet known, which value will be used as documentID!
//
char	gDocumentID[];

The commands relevant for checkin and checkout are described in the priint module.

The status of checked out documents is locally saved in an XML file. This file is located in the Werk II preferences directory and is named checkout.xml.
When displaying the publication tree, the states are requested from the server or database again and updated.
With the menu command Delete Local State you can delete the state of the current connection. You should only modify this data manually (by editing or deleting the XML file) in emergencies.

The parameter documentID required by most priint-commands is a key by which - together with the current mandant - priint:cometserver can uniquely identify a file resource - regardless of the publication management. Publication management has to ensure that mapping publication data sets to documentIDs is possible. For simplicity, we always assumed in the examples that the StringID of a publication data set corresponds to the documentID on the priint:cometserver.

To make a document / file on the priint:cometserver usable, it has to be uploaded or registeres with the respective documentID. It does not have to exist at this point in time (e.g. if you want to generate a new document from a model document later). You can find more specific information about this in the priint:cometserver documentation.

To install the tables and data required by the panel, please open the installation directory and execute the following SQL files in order :

@'Daten/Documents/00_Condition.sql'
@'Daten/Documents/01_Documents.sql'
@'Daten/Documents/02_Documents_PanelStatements.sql'

If you also want a default variation of the configurable search, execute the remaining SQL files.

For an example configuration of the checkin / checkout extensions, see above.