A JavaScript Date Library ... just throwing it out there ...

[WestPress]

I found an awesome library for playing with, and formatting, dates.

I present "Datejs"

This library is awesome. I just stuck the code in the "JavaScript Globals ..." area in the rules editor, and now I have some really cool latitude over how I accept user input in my MarcomCentral PrintOnes/Stores or even on the Desktop (via some data source) for templates that require it. I think this can benefit every FusionPro user, Designer or Desktop alike.

My goal is that I can present an input field in the PrintOne/Store without any guidance and irregardless of how the user inputs the date, I can format it with very little effort.

[WestPress]

So a simple example (again, making sure that you have already pasted the contents of date.js into your globals):

var d1 = Date.parse(Field("Expiration"));
return (d1.toString('MM/dd/yy'));

This takes a string of input like, "5 days from today" and formats it to read, "06/29/11" like your template might require.... It could be "5 days from now," or "June 29 2011," or "jun 29, 2011," or "06292011," or "next april," or "next friday," etc.

You can format it many different ways....

[Dan Korn]

Thanks, that's awesome stuff!

Our decision many moons ago to choose JavaScript as the language for FusionPro rule scripting has turned out to be a huge win, since JavaScript has pretty much taken over the world in the last few years, and there are now tons of great libraries like this around. Of course, many of them are web-specific, as JavaScript's primary use continues to be for client-side web page scripting; however, this is a nice generic library that works right out of the box in just about any JS context, including FusionPro. I dare say that some of this library's date formatting capabilities, and certainly its parsing capabilities, exceed those of FusionPro's built-in functions. Of course, we're not quite Google.

By the way, instead of copy-and-pasting all the code from the Date.js file into your JavaScript Globals, you could add it as a Plain Text Resource to your job and put this line in the Globals instead:

Load(Resource("Date.JS").value);

[WestPress]

Heh, that's why you're the JavaScript Guru! That certainly makes for a much cleaner "Globals" area It would have taken me working on several templates before that even would have occurred to me.

I do like Java/JavaScript and appreciate that you chose JavaScript for the foundation of the rules feature of FusionPro.

[WestPress]

Well Dan,

I tried to load the JavaScript library into "Globals" the way you suggested in a new template I am working with. I loaded the "date.js" file as a plain text file resource. In my JavaScript Globals I have included the resource using the code you suggested:

Load(Resource("date.js").value);

My text rule, "{rule_FormatDate}" validates okay when I am editing it, showing the correctly formatted date, even the "Results" field of the building blocks menu shows the correct formatted date. But, the preview and subsequent composition returns "{rule_FormatDate}" (the name of my rule) instead of the formatted date.

[Dan Korn]

Originally Posted by cdaters

My text rule, "{rule_FormatDate}" validates okay when I am editing it, showing the correctly formatted date, even the "Results" field of the building blocks menu shows the correct formatted date. But, the preview and subsequent composition returns "{rule_FormatDate}" (the name of my rule) instead of the formatted date.

What does the log (.msg) file say?

[WestPress]

This is what is contained in the .msg log:

internal, line 1: Error: can't open /test_deleteme/date.js: No such file or directory
Failed to process JavaScript globals
Job started 15:18:51 - 1309187931.
Creator: FusionPro(TM) Designer 7.1P1c
Computer Name: sysad-m01
Current working folder: /
Template File: /test_deleteme/ScratcherBC_Spring_fp.dif
Input File: /test_deleteme/ScratcherBC_Spring.txt
Job Config File: /test_deleteme/ScratcherBC_Spring-Output.cfg
rule_formatDate, line 3: Error: illegal radix 0

Yes, the date.js file does exist at that location...

Initially, I was wondering if it might have something to do with OS X thinking the .js was not necessarily a text file. So, I changed the extension to .txt but that had no effect either. I even moved it to a top level directory thinking the path might have contained too many characters for the parser. What is weird is that the rule validates okay, but the composition fails.

[Dan Korn]

Originally Posted by cdaters

This is what is contained in the .msg log:

internal, line 1: Error: can't open /test_deleteme/date.js: No such file or directory

...
What is weird is that the rule validates okay, but the composition fails.

Oh, you're on Mac. The Load function is broken there. Sorry about that.

It's an issue of HFS vs. POSIX file paths. HFS is the older Mac OS 9-style file reference with colons, while POSIX is the "new" Unix-y OS X-type syntax with forward slashes. Over the years of dealing with the OS 9 to OS X transition, along with all the other myriad changes Apple has made to their APIs, we've patched just about every part of FusionPro to be able to handle both HFS and POSIX path specifications (as well as Windows DOS-type path specifications) interchangeably. However, the Load function in JavaScript is one that we missed. The thing is that, when you're validating the rule, JavaScript is running in a native Intel OS X app, which expects POSIX paths, which is what FusionPro is giving it, and that works fine. But at composition time, you're in the CFM/PowerPC FusionPro app, which expects HFS paths at a low level, so it doesn't work.

This will be fixed in the next 7.2 release.

Also, we're planning to port FusionPro to a modern, Intel-native, BSD-based OS X app in the second half of this year, which should finally get rid of any remaining HFS path dependencies (and actually deprecate support for HFS).

[WestPress]

You know, this actually validates a discussion I had with Alex some time back about Universal builds vs. Intel builds for OS X.

I had asked him when/if there would ever be an Intel build of FusionPro, that I had noticed it was still a Universal build, and that I would love to see an Intel build thinking of situations just like this.

He had mentioned that there was no reason for an Intel build that the Universal build was working just fine...

[Dan Korn]

Originally Posted by cdaters

You know, this actually validates a discussion I had with Alex some time back about Universal builds vs. Intel builds for OS X.

I had asked him when/if there would ever be an Intel build of FusionPro, that I had noticed it was still a Universal build, and that I would love to see an Intel build thinking of situations just like this.

He had mentioned that there was no reason for an Intel build that the Universal build was working just fine...

Okay, well, we're getting quite far afield from the original subject of this thread, but I can tell you that this isn't really an Intel vs. PowerPC vs. universal binary issue. I'll try to explain.

First, since we're being technical, the FusionPro app (the composition engine) is not a universal binary, it's a CFM/PEF PowerPC app, which runs under the Rosetta VM (the PowerPC emulation layer) on Intel Macs. The FusionPro Acrobat plug-in, on the other hand, is a bundle containing a Mach-O universal binary with both PowerPC and 32-bit Intel (i386) architectures, to match the host application, Acrobat. (Of course, Acrobat, and therefore our plug-in, do run natively as Intel executables on most modern Macs, but we still support PowerPC Macs, as does Adobe, thus the need for a universal binary instead of an Intel-only executable.)

The reason that the FusionPro app uses HFS paths natively doesn't really have anything to do with the fact that it's a PowerPC app instead of a native Intel app or a unversal binary. It's a consequence of the tools and APIs used to build it. Specifically, it's because it's built in CodeWarrior instead of Xcode, which not only limits it to PowerPC and the CFM architecture, but it also makes it use HFS paths by default because it relies on CodeWarrior's Metrowerks Standard Library (MSL) runtime.

Now, we have actually patched the CodeWarrior MSL runtime to accept POSIX file paths as well as HFS paths, to facilitate interoperability between the FusionPro app and other modern OS X components, most especially our Acrobat plug-in. However, the JavaScript runtime is a third-party component from Mozilla, and the version of the JS runtime used by the FusionPro app is still an older-style CFM library which expects HFS paths. We've patched most of the interface points into the JS library to convert POSIX paths to HFS, but the Load function is one that we missed. (I'm sorry to say that it's not a widely used feature.) The JavaScript runtime used by the Acrobat plug-in, however, is a native Mach-O binary, just like the rest of the plug-in, so it uses POSIX paths by default (and in fact, doesn't work with HFS directly).

Anyway, other than a few fairly minor issues, such as this one with the Load function, the old-school CFM FusionPro app has indeed been working fine for quite some time, as Alex noted. So we haven't had any major impetus to change it. To paraphrase a wise man: "Prudence, indeed, will dictate that Applications long established should not be changed for light and transient causes; and accordingly all experience hath shewn that mankind are more disposed to suffer, while evils are sufferable than to right themselves by abolishing the forms to which they are accustomed."

However, the time eventually comes, "when a long train of abuses and usurpations, pursuing invariably the same Object evinces a design to reduce them under absolute Despotism." Or in this case, Apple decides to change things on us for the umpteenth time. (PowerPC to Intel, HFS to POSIX, 68K to Carbon to Cocoa, QuickDraw to Quartz, GrafPorts to HIViews to NIBs to xibs, dylibs to frameworks, little-endian to big-endian back to little-endian, Leopard to Tiger to Lion, to bears, oh my!)

Specifically, the upcoming Mac OS 10.7 "Lion" removes the Rosetta subsystem, which will render our current architecture unusable. Therefore, we do need to finally bite the bullet and port the FusionPro app to a modern Mach-O app which can run natively under Intel. We're targeting this for FusionPro 8. We will likely drop support for PowerPC Macs and HFS paths in that version as well.

Then we can rest, at least until Acrobat goes to 64-bit.