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.

Please note that the StringID is only expected for <hasstringids>1</hasstringids>! In XML offline connections, the panel statements for check-in and check-out are also irrelevant, and at least panel statement 114 must be empty (or missing entirely).

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, ""                  <!-- ID, StringID only if hasstringids = 1 -- >
         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) 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>

The following are examples of correct panel statements to fill the panel in SQL connections. 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 fourth value (after the 3 numerical IDs) is expected to be the StringID, all following column indices are thus incremented by 1.

[Since v5.0 R37333 and for XML offline and ODBC connections only] An empty name in the name column automatically creates a folder entry with the default icon . The path in the path column does not have to exist for this and may be empty too. Please note that even in these cases, the arrow for expanding the subentries is only displayed if subStatementID is defined.

Before you hurt yourself: Please remember, for XML Offlines and ODBC connections, the panelstatement 114 must be empty or undefined!

The elements (files and folders) of existing folders can be loaded automatically. To do this, use the IDs -1 to -4 in subStatementID. For subStatementIDs -1 to -4, the title specification is ignored and the path is automatically used as the title! The following elements are added to the panel:

Here is a panel statement 36 that you can use to load the following entry in documents.xml as a folder entry for your desktop.

<panelstatement>
	<id>36</id>
	<usage></usage>
	<domain>Lade die IDs der Liste der Dokumente gemäss den Sucheingaben in der Palette</domain>
	<statement>
		"documents.xml"
		select
			id, img, 0,
			name,
			title,
			info2,
			info3,
			"",
			"",
			domainname,
			path,
			url,
			canoverrideurl,
			canoverridelocal,
			elements,
			img
		node documents.document
		where 		id > ?
		and	(domainid = ? 	or 0 = ?)
		and parentid = 0
		$1 $2 $3
	</statement>
	<in_parameters></in_parameters>
	<out_parameters></out_parameters>
	<description></description>
	<hasstringids>0</hasstringids>
</panelstatement>

And here's a document definition that will create a folder entry for your current desktop using the above panel statement 36. The entry will add all folders and files of your desktop as subentries if you open it.

<document>
	<id>70</id>
	<parentid>0</parentid>
	<title>$DESKTOP</title>
	<url></url>
	<path>$DESKTOP</path>
	<name></name>
	<canoverrideurl>1</canoverrideurl>
	<canoverridelocal>1</canoverridelocal>
	<domainid>1001</domainid>
	<domainname>Bereich 1001</domainname>
	<firstpage>0.000000</firstpage>
	<info>info1</info>
	<info2>info2</info2>
	<info3>info3</info3>
	<img>2001</img>
	<elements>-2</elements>
</document>

And here's a screenshot:

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);

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 Publication Action (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 Publication Action (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.

In XML offline and SQL connections, panel statement 114 must be empty or undefined!

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.

In data connections without a Publication Server (XML offline, XML online, ODBC), the documents are opened by clicking on the button in the first column. If a parent (aka master) document is specified, a copy of this document is first created at the specified target path. The parent document may be specified with a valid URL (http or https) and is automatically downloaded in these cases. Incomplete paths are resolved relative to the current data folder (or the XCache for SQL data connections).

It a document is open, clicking in the first column of the Publication panel brings this document to the foreground. After that, an additional own Publication Action can be performed.

Please note that there is no automatic check-in for data connections without a Publication Server.

The buttons in the first column of the Publication panel can be assigned custom actions. The actions can be implemented in cScript or priint:Python.

Actions for publications are performed in two steps:

1. Panelstatement 96 calculates the ID of the desired Action, see here.
2. If an action is defined for a publication (>0), the script defined in the action is executed, see here.

The statement for calculating the ID of the Action to be executed must be a direct statement in the current data pool language (e.g. xmlquery, XPATH, SQL, soap). The statement expects up to four (optional) input parameters (i.e. question marks) in the where conditions, namely the three IDs of the current publication and its StringID.

In addition, the generally supported tags such as <ID>, <ID2>, <folder>, ... are defined here. The parent properties of an entry you can get using the parent tags of the Publication panel. To get proporties of the publication istself, omit the <parent.. This only works when calculating the action ID, it does not work in generell! For example, simply use <Info1> to get the info1 of a publication.

Here are some examples of valid panelstatements that can be used to define the ID of a publication action.

JEach nesting depth has its own publication action (SQL).

select 900+<depth> from dual;      

Each nesting depth has its own publication action (XML). Instead of dual, use any (but existing) XML file.

"datafiles.xml"                        
select 900+<depth>    

This publication action takes a break at the weekend.

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

Three question marks may be included in the statement; they will be replaced by the current ID of the publication. The following two statements are identical

select id%3 from ... where ID = ?       
select id%3 from ... where ID = <ID>   -- Die ? sind optional

If an action is defined (>0) for a publication, the script defined in the action is executed for the publication that was clicked on. Publication actions must be implemented in cScript or priint:Python. The following global variables are defined in the publication actions:

*gDocumentStatus = 1401;

showmessage ("<Name>, <DokumentInfo>, <parent.DokumentInfo>");

Here is a very simple example of a Publication Action that only shows a few messages.

#pragma plain

int main ()
{
	char 		projID [512];
	int 		altkey	= system::altkey ();

	if (!gNewOpened)
	{
		if (altkey)
		{
			strcpy(projID, "<parent.parent.Content_STRINGID>");
  			wlog ("", "Documents clicked : %d\n", gClicked);  
  			wlog ("", "%s\n", projID);  
  			
			showmessage ("<State>\n<ID2>\n<parent.parent.ID2>\n'%s'", gDocumentPath);
		}
	}
	else
	{
		if (gConverted) showmessage ("Document successfully converted and opened");
	}
	
	return 0;
}

[Since v5.0 36660] By clicking the button at the bottom left of the panel, you can process all selected documents in the panel.

In priint:suite PubServer connections, XML offline and ODBC/SQL data connections only! The jobs queue processing of publication documents cannot be supported in other data connections, including customer-implemented SOAP connections. To collect the documents, use a script similar to the example from publication::get_subnodes. To build and start a jobs queue with these documents, please use the functions of the jobs module.

Of course, you can also collect the selected documents in and below the selection of the Publications panel by using a script. You can find an example of this here. But when you get started and want to process all the documents, you will quickly realize that there are strict limits to this procedure: InDesign® will keep all the documents that you have carefully closed and reentered in memory until the end of the script (at the next idle time). Unfortunately, there is no way to prevent this - unless you start processing during an idle time phase. And this is exactly what Jobs Queue Processing does.

For that, at first the DocumentIDs of all selected documents and all documents of all selected publications are collected. Then you will be asked for a function to process the documents. The following script sources are possible:

• All available Job Queue Scripts of the current data pool are shown in a dialog. In order for scripts to be shown here, they must have the ClassID 64.
• By holding down the OPTION-ALT key you can also select the processing script directly as a file.

Holding down the SHIFT key copies the script for creating the queue to the clipboard (and does not start it).

What is done with the documents depends entirely on the implementation of the selected script. In most cases, however, these scripts will check out the selected documents, edit, save and check in them again. A complete description of the Jobs Queue Scripts and their behavior can be found here.

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.