SimpleDateFormat in javascript

/**
 * SimpledateFormat javascript class
 *
 * var reverseDateFormat = new SimpleDateFormat("YYYYMMdd");
 * var reverseDate = reverseDateFormat.format(new Date());
 * http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html
 *
 * **/
function SimpleDateFormat(formatString){
 this.formatString = formatString;
 this.monthNames = ["January","February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"];
 this.dayNames =   ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"];

 this.format = function(aDate){
 var localFormatString = formatString;
 // The order is significant
 /* YYYY */  localFormatString = localFormatString.replace(/Y{3,}/g,     "\" + (aDate.getFullYear()) + \"");
 /* YY   */  localFormatString = localFormatString.replace(/Y{2}/g,      "\" + ((aDate.getFullYear()).toString().substring(2)) + \"");
 /* MMMM */  localFormatString = localFormatString.replace(/M{4,}/g,     "\" + (this.monthNames[aDate.getMonth()]) + \"");
 /* MMM  */  localFormatString = localFormatString.replace(/M{3}/g,      "\" + ((this.monthNames[aDate.getMonth()]).substring(0,3)) + \"");
 /* MM   */  localFormatString = localFormatString.replace(/M{2}/g,      "\" + (aDate.getMonth()+101).toString().substring(1) + \"");
 /* ww   */  /* don't have time to implement this today */
 /* WW   */  /* don't have time to implement this today */
 /* DD   */  /* don't have time to implement this today */
 /* dd   */  localFormatString = localFormatString.replace(/d{2}/g,      "\" + (aDate.getDate()+100).toString().substring(1) + \"");
 /* FF   */  localFormatString = localFormatString.replace(/F{2}/g,      "\" + (aDate.getDay()+100).toString().substring(1) + \"");
 /* EEEE */  localFormatString = localFormatString.replace(/E{4,}/g,     "\" + (this.dayNames[aDate.getDay()]) + \"");
 /* EEE  */  localFormatString = localFormatString.replace(/E{3}/g,      "\" + ((this.dayNames[aDate.getDay()]).substring(0,3)) + \"");
 /* EE   */  localFormatString = localFormatString.replace(/E{2}/g,      "\" + (aDate.getDay()+100).toString().substring(1) + \"");
 /* a    */  /* don't have time to implement this today */
 /* HH   */  localFormatString = localFormatString.replace(/H{2}/g,      "\" + (aDate.getHours()+100).toString().substring(1) + \"");
 /* kk   */  localFormatString = localFormatString.replace(/k{2}/g,      "\" + (aDate.getHours()+101).toString().substring(1) + \"");
 /* KK   */  /* don't have time to implement this today */
 /* hh   */  /* don't have time to implement this today */
 /* mm   */  localFormatString = localFormatString.replace(/m{2}/g,      "\" + (aDate.getMinutes()+100).toString().substring(1) + \"");
 /* ss   */  localFormatString = localFormatString.replace(/s{2}/g,      "\" + (aDate.getSeconds()+100).toString().substring(1) + \"");
 /* SS   */  localFormatString = localFormatString.replace(/S{2}/g,      "\" + (aDate.getMilliSeconds()+1000).toString().substring(1) + \"");
 /* z   */   /* don't have time to implement this today */

 localFormatString = "\"" + localFormatString + "\"";
 //prompt("localFormatString", localFormatString);
 var formatedDate = eval(localFormatString);
 return(formatedDate);
 }
}

Limiting the textarea size in forms

maxlength is only valid for text instances, not textarea ones. The DTD of datacapture documents says so. Limiting the size can be done with a nice little regulare expressio. For example, limiting to 300 characters requires the following regular expression:

<textarea validation-regex="^.{0,300}$" required="t" rows="10" cols="90" wrap="virtual" />

javascript call from the server with IWDatacapture.callServer

formAPI making server requests can be useful when you need the server to give you information that is not readily available in the datacapture form. This could be DCR meta data for example that you need to read when loading the form.
Part one: making the call

IWDatacapture.callServer takes 3 parameters:

• the URL of the request to make, this will be done via a hidden form and the response will be targetted in a hidden iframe.
• the data to pass to the request. This is normally a javascript object.
• a boolean indicating if http get method is used (true) or post method is used (false).

The URL is easily sorted, we can get it with a few lines of code.

var server = window.location.hostname;
var url = "http://" + server + "/iw-bin/myScript.ipl";

the data is also quite straightforward.

var data = new Object();
data.filePath=IWDatacapture.getDCRPath();
data.metadataField='myMetaDatafield';

This will be translated into:

<form action="http://teamsite/iw-cc/myScript.ipl" method="post" target="hiddenFrame">
<input type="hidden" name="filePath" value="/default/main/acme/WORKAREA/work/templatedata/acme/article/data/myArticleDCR" />
<input type="hidden" name="metadataField" value="myMetadataField" />
</form>

now we have what we need, we can do a HTTP request to the specified url and pass the name/value pairs at the same time. I recommend you do a POST request so as not to have any problems with the size of the parameters. The ones used in this example are quite tiny, but you could have bigger ones and more of them.

IWDatacapture.callServer(url,data,false);

Part 2: receiving the call

This is where it starts getting interesting. The business logic of the request needs to be processed and then a response given back to the form. Our script resides in httpd/iw-bin and is called myScript.ipl (make sure you change its permissions to be executable. It gets me everytime!).

#!/apps/interwoven/teamsite/iw-perl/bin/iwperl -w
$!=1; # flush the output as soon as you have it

use CGI;

my $cgi = new CGI;
print "Content-type: text/html; charset=utf-8\n\n";

print qq!<html>
<head><title></title></head>
<body>Hello world</body>
</html>!;

Once you have the cgi script in place, invoke it directly to check you get a response from the server and that everything is ok.

http://teamsite/iw-bin/myScript.ipl

All is good if you get a response. In my example, I need to get request parameters to figure out what I need to do and on which file.
#!/apps/interwoven/teamsite/iw-perl/bin/iwperl -w
$!=1; # flush the output as soon as you have it

use CGI;

my $cgi = new CGI;

# retrive the request parameters
my $filePath=$cgi->param('filePath');
my $metadataField=$cgi->param('metadataField');

my $customOutput=qq!<div>
\$filePath:$filePath<br />
\$metadataField=$metadataField<br />
!;

print "Content-type: text/html; charset=utf-8\n\n";

print qq!
<html>
<head><title></title></head>
<body>
$customOutput
</body>
</html>!;

Again, invoke the script directly, this time with parameters and get the values output directly in the response. Right, we’re on the right track.

http://us1529/iw-bin/get_dependent_URI_title.ipl?filePath=/default/main/acme/WORKAREA/work/templatedata/acme/article/data/myArticleDCR&metadataField=myMetadatafield

Now, we need to do some teamsite stuff and retrieve the metadata field on the specified file path that was passed.

#!/apps/interwoven/teamsite/iw-perl/bin/iwperl -w
$!=1; # flush the output as soon as you have it

use CGI;
use TeamSite::Config;

my $iwhome = TeamSite::Config::iwgethome();
my $iwmount = TeamSite::Config::iwgetmount();
my $cgi = new CGI;

# retrive the request parameters
my $filePath=$cgi->param('filePath');
my $metadataField=$cgi->param('metadataField');

$command="$iwhome/bin/iwextattr -l -r \"$metadataField\" \"$filePath\"";
my $metadata=`$command`;
my ($metadataKey,$metadataValue)=split("=",$metadata);

my $customOutput=qq!<div>
\$iwhome:$iwhome<br />
\$filePath:$filePath<br />
\$metadataField=$metadataField<br />
\$command:$command<br />
\$metadata=$metadata<br />
\$metadataValue=$metadataValue<br />
</div>
!;

print "Content-type: text/html; charset=utf-8\n\n";

print qq!
<html>
<head><title></title></head>
<body>
$customOutput
</body>
</html>!;

Part 3: using the results the form
Ok, so we have a form, it makes a call to the server and then what... nothing shows up, how do we use the results.
In order to understand that, we need to understand that the structure of the calling form. It makes an AJAX call to the url we pass and the response is placed in a hidden iframe. That means that in Javascript world, "parent" is the datacapture form. the scripts in the form are not directly on the form. They are also in an iframe that we can access through the method parent.getScriptFrame(). All the methods we may have defined are accessible through there from the cgi script's response.

Say in our DCT we create a function callServermyScriptResponseHandler:

callServermyScriptResponseHandler(metadataValue){
  alert(metadataValue);
  //... do other formAPI stuff here with the value ...
}

We can call this function from the CGI script’s document

<body onLoad="parent.getScriptFrame().callServermyScriptResponseHandler('$metadataValue')">

Job done.

myScript.ipl

Using XPath to read a value

Often, you want to parse an XML document using xpath and retrieve values, for example to read the DCR’s title field and set the metadata value with it. Here’s a quick code snippet to do that:

try {
 DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
 DocumentBuilder documentBuilder = documentBuilderFactory.newDocumentBuilder();
 Document dcrDocument = documentBuilder.parse(new File(filePath));
 XPathFactory xPathfactory = XPathFactory.newInstance();
 XPath xPath = xPathfactory.newXPath();
 String titleXPathExpression = "/article/title";
 String title = (String)xPath.evaluate(titleXPathExpression, dcrDocument, XPathConstants.STRING);
 System.out.println("found DCR title " + title); CSExtendedAttribute[] extendedAttributes = {new CSExtendedAttribute("TeamSite/Metadata/Title", title)};
 cSSimpleFile.setExtendedAttributes(extendedAttributes);
} catch (Exception e) {
 Logger.getLogger(this.getClass().getName()).log(Level.SEVERE, "unable to set metadata title",e);
}

Introduction to customising the meta data form

Customising the metadata form can help improve the quality of your content and your processes of the content. By using meta data, you can pass instructions to workflow for example for how to process each file (publish to that server, expire after a certain date…)

In order to customise the meta data, you need to go into local/config and have a look at two files: metadata-rules.cfg and datacapture.cfg.

datacapture.cfg defines a set of rules and their items. Think of a rule as a set of fields that make up your meta data. For example, an copyright rule would include source name, copyright information, address, telephone and email. An expiry rule would be expiry date, expiry action (notify, delete).

metadata-rules.cfg defines under which circumstances a certain rule is to be used. For example, an article may have the author rule applied to it and the expiry, whereas a company DCR and its share price is updated daily and never expired, therefore the expiry rule does not apply to it. If more than one rule applies to one file, the fields they contain are merged on the metadata capture form and displayed to the user for entry.

Recently, rules can have their own file, which makes them easier to manage. They reside in local/config/tagui/ruleset60. It is probably best to name them the same as the rule.

The metadata capture form uses FormsPublisher to render it, therefore it follows the same characteristics as a Formspublisher data capture form, including FORMAPI scripting.