For government employees to use online purchasing applications like Four51, they are required to be compliant with something called FIPS, which stands for the Federal Information Processing Standard. This standard requires a government employee’s browser to be configured to have non-FIPS-compliant cipher suites disabled. This means that those sites that are non FIPS compliant would not operate in the user’s browser. Because Four51 uses a FIPS compliant cipher suite called DES-CBC3-SHA, the user’s browser will work with the Four51 application.

There is a good article by Roger Grimes of Infoworld that you may want to read if you are interested in more information on the Federal Information Processing Standard. The article can be found at http://weblog.infoworld.com/securityadviser/archives/2008/02/is_your_web_sit.html

In the meantime, you can sleep easy, knowing that Four51 has it all taken care of.

I’m going to supplement that demo with a few additional pieces of information. We’ve created a Four51 App Exchange wiki. I want to answer some expected questions regarding the Four51 Toolbar, and I’ll demonstrate a document action that I believe will be very popular.

First, the wiki. Hopefully you’re aware of wiki’s. Wikipedia is the headliner. I don’t think I know any person that hasn’t at least visited that site. I feel that Pageflex’s Document Actions feature open limitless possibilities for your products. I attempted to identify the most obvious uses and created the Four51 Actions library. That library makes it possible for you to take advantage of this powerful feature without having to write your own code. However, it does not expose all the capabilities of Document Actions. I want to encourage you to examine them. The API reference is installed with your upgraded version of Pageflex Persona. I understand the learning curve involved, so I felt that allowing you to see how we’ve created the Four51 Actions library would be the most helpful jump start in this process. The library is open source and each action is defined in the wiki. Please come join the community. Post comments in the discussion pages, or even contribute new document actions to be included in the official library.

Nothing has been more requested for projects than the ability to customize text in the spec form. Pageflex’s .EDIT feature (I believe they refer to this as Free Edit now) is an impressive and robust offering. However, it is generally not suited to the products you offer to your customers. The need to basically design a layout is far above and beyond most customers needs. I decided to focus on the most requested capability, the text styling needs. The Four51 Document Actions Toolbar allows for bolding, italicizing, underlining, and a few other capabilities within the spec form. I predict two questions to be asked immediately: What about setting the font type, and color? There are limitations with HTML that prevent those features from being applied. The toolbar’s editing feature allows the text to be displayed in the spec form just as it would appear in the rendered template. Because HTML does not allow for more than 7 defined fonts on one page there is no way to produce the “what you see is what you get” aspect. Additionally, for a website to display text in a particular font every individual visiting that page must have the same font installed locally. Based on the 8,000 installed fonts for the rendering servers, not many people would have the fonts installed on their computers. Allowing for color choice is also prevented by a particular limitation of technology. HTML requires RGB color definitions. If you needed the print production output to be CMYK there is no formula for converting RGB to CMYK. The “what you see is what you get” aspect is again broken. Fret not. There are document actions that allow you to customize text properties with all of these options, but they will not work within the “what you see is what you get” functionality of the toolbar.

Along the lines of text styling I have set up a demo product named “Documents Actions Paragraph Styling” that shows the capabilities of the DefineParagraphStyle Four51 Document Action. The open textbox has 4 properties that are definable. Go to the site to see it in action, and also download the project files I created.

I hope you all are as excited about the possibilities these new service offerings bring you. When asked if something can be done now my answer is always “You can do anything with Document Actions”. Let’s all push the limits and see what wonders we can create.

The systems management team at Four51 asks itself that very question, and many others, as we design and maintain the hardware backbone of the Four51 network. Four51 maintains a fully-redundant, state-of-the-art network that has stood up to the scrutiny not only of our IT industry peers, but to a Payment Card Industry (PCI) audit (arguably one of the most rigorous IT audits in the industry). As an example, the database environment, where all of your information is stored, has twice the amount of hardware required to run the Four51 network dedicated to it at all times. If something happens and one of the database servers decides to call in sick, one of the other servers automatically and immediately picks up the slack with no data loss or downtime. It’s the IT equivalent of having two brand new cars in your garage, but one of them is a spare in case one needs to see the mechanic.

Our dedication to providing a fast, reliable network doesn’t stop at simply having extra hardware on hand. We have an entire team that constantly monitors the network for performance problems or potential bottlenecks. We have an intelligent monitoring system in place to determine when the application may be performing poorly before it impacts you, and most of the time performance problems are corrected before they are even noticed. Combine this with an off-site backup and recovery plan, and short of a hurricane coming up the Mississippi and wiping out Minneapolis there really isn’t much that can take the network down.

Sure, cell phones still go off at 3AM waking Jeff and I up to tell us that one of the servers might be a little cranky. Sometimes, regardless of how much you plan things out, things just happen. However, I feel a great deal of pride when I read an article like the one mentioned above and I can say to myself “that wouldn’t happen at Four51.” We’re proud of our infrastructure and our network….and as our valued clients, you should be too.

Cheers.

Ross

The two sentence summary: At submission time, a standard buyer order can have one or more required approvals attached to it. Until all attached approvals are approved, the order can’t proceed.

That sounds obvious, but how do orders get approvals attached?

At its core the system is pretty simple–Four51 grabs the list of approval rules for the buyer company and looks at each rule on the list. If a rule applies to the submitting user, the order meets all the requirements specified in the rule and the submitting user isn’t one of the approvers, an approval is attached to the order. After the rules are processed, approving parties are notified and pending approvals appear on the order view page. When an order is approved, the process is repeated, with the list checked using the approving user instead of the original submitting user.

Eventually, the order clears the list check with no pending approvals and goes through to the seller. Alternately, the approval is declined and the seller will never see it.

In reality, it’s a little more complicated than that.

Each buyer company actually has two lists of rules, configured under Buyers->Approval Rules. There’s a parallel list and a sequential list. When an order is submitted, every rule on the parallel list is checked. The sequential list, however, is checked only until the first match is found. Because rules following a match will not be evaluated, rule order matters for the sequential list. You only need to care about which list you use if you have a workflow that requires multiple approvers or chains of approval, and I’ll get into why you may need both in a later post. If in doubt, just use the parallel list.

The biggest task in configuring approval rules is figuring out how to break your workflow down into a set of rules. I’ll walk you through this in my next post.

Chris G

As I said above, there are two definitions available: Countries, States. Only those two now because I reference the list we already use in the site, and I couldn’t think of any other consistent lists that are used frequently.

The defined drop downs widget is another of the type that allows you to define it in your HTML instead of scripting. It’s extremely simple to use:

Now, you know it doesn’t end there. We had to add some fanciness and flexibility. You have to use scripting to take advantage of those capabilities.

There are additional properties and events available that you can read about in the Spec Form API documentation. You can go to my demo site to find the “Spec Form API Playground.” I’ve added an example of both types of DefinedDropDowns.

Happy Monday.

The previous versions of Pageflex have allowed us to submit over 5.5 million jobs. Yesterday, we began running preview jobs against the new Pageflex 6.1 server in our production environment and discovered the new architecture rendered the 10,000 some jobs that were submitted quicker than the version it is replacing.

However, as with any new release of software, this hasn’t been without issues. The new Pageflex architecture required Four51 (and you) to make several changes to the nearly 90,000 variable data project files we host. Some of these changes were scripted, and others we have asked and are asking you to perform.

Luckily, there is light at the end of the tunnel.  In the next few weeks we will continue to work with you to ensure your existing products work with preview, proof and production jobs. When we are confident that the transition has been made for existing products, the plan is to support project files created in the newest version of Pageflex. Among other features, these newer projects will support text on a path, document actions and simple impositions. Though transition is sometimes painful, we do like what we see at the other end of the tunnel!

John

First, obviously, you need two specs for the Name and City. Then create another text spec named Comma. Set the default value to: “, “. Note that I put a space after the comma.

Secondly, add the new Comma spec to your form. You can place it anywhere because we’re going to hide it from the user. Once in the form, go to your Advanced Scripting tab and hide the spec:

Finally, go to the Variant Identifier page and add the spec in the order you want to display them in the name.

All of your variants will be saved like so: Joe Nathan, Minneapolis.

Control over user input is such an important facet of most variable products, especially products revolving around Corporate Identity. How many times have you had to create 3 or 4 variables for a simple phone number just so you can control the delimiting character? Not to mention date input. It’s a hassle and simply creates additional development time. The solution to these issues is masked input. Let’s review what it is and how it works in spec forms.

First, masked input is nothing more than a convention that forces users to enter information in a specific pattern. You define a pattern, the pattern is presented to the user for input and then their input is controlled by that pattern. Let’s take a look at an Advanced Script example for controlling a phone number.

Here is a snippet of all the examples on the demo product.

As for the patterns themselves, there are predefined placeholders.

• a - represents an alpha character (A-Z, a-z)
• 9 - represents a numeric character (0-9)
• * - represents an alphanumeric character (A-Z,a-z,0-9)

Any other character is treated as a static character in the pattern. The phone example shows an extension aspect. The “x” in the pattern is static and therefore not editable.

Lastly, all input including the placeholder characters are submitted for rendering So the “$” in the Cost mask is part of the saved variable; no need to specify a prefix or hard code the character in your template file. Nice and tidy submission.

As always, you can go to my demo site and find the “Masking Input Demo” product to see this example in action.

In this post, I’ll try to cover what OCI integration is, and what it provides both print buyers and print sellers.

OCI stands for Open Catalog Interface. It enables SAP users to integrate purchase order processing with a web-based supplier catalog (Four51). From a user’s perspective, the workflow looks like the following:

1. Users log onto their SAP system and open a new purchase order.

2. Users click a link to shop in a Four51 website which opens a web browser and logs them into your Four51 website automatically.

3. Users shop on Four51 and place items into their shopping cart.

4. When ready, they click “Submit” in the Four51 shopping cart check-out.

5. Four51 sends the order back to the SAP system in an electronic transimission. The user is simultaneously redirected back to their SAP system.

6. The order is routed through the SAP system’s established requisition and
approval process.

7. The SAP System confirms the order with Four51 via a electronic purchase order. The order then appears in a Four51 Administrative interface.

The benefits of OCI to an SAP print buyer are significant:

1) They can offload the management of product skus to the print seller rather than maintaining them in their SAP database.

2) OCI provides an enhanced, seamless user experience by tying SAP and Four51 together into one workflow.

3) OCI Integration reduces purchasing costs.

4) OCI prevents renegade spending, since purchase orders flow through the buyer’s established financial control and approval processes inside SAP.

The benefits of OCI to a print seller are also tremendous:

1) There aren’t many sellers that can support OCI, so being able to offer it to your buyers via Four51 is very unique.

2) OCI improves data sharing with your customer.

3) Variable documents aren’t a native capability of SAP, so you’re offering something they can only get through you.

4) Your cost to process purchase orders is also reduced.

All-in-all, OCI projects are fairly straightforward and easy to implement. Four51’s new OCI platform is very flexible and works easily with SAP. If you have a customer that uses SAP and you would like more information, contact your Four51 representative.

-Owen

Enter the Spec Form API. Reference a selection spec (or any SELECT list on your spec form using the “get” function) from the Advanced Scripting tab and that Ford Escort of an API is magically transformed into a turbo-charged BMW. Your drop-down list object is “decorated” with a wealth of new methods for adding, removing, hiding and showing options, as well as shortcuts for retrieving information. Here are the SELECT list-specific methods of the API in a nutshell:

Methods that return a value:
getOptionIndex, getSelectedOptionIndex, selectedValue, selectedText

Method for selecting an option:
selectOption

Methods for adding options:
addOption, insertOption, addOptions

Methods for hiding/showing/removing options:
hideOption, hideOptionAt, hideOptions, hideOpionRange, hideOpionRangeAt, hideAllOpions, showOption, showOptionAt, showOptions, showOpionRange, showOpionRangeAt, showAllOpions, removeOption, removeOptionAt, removeOptions, removeOpionRange, removeOpionRangeAt, removeAllOpions

The purpose of this article is not to document each method (see the Spec Form API docs for that), but rather to give you a feel for what you can do with them by walking through an example. A common scenario is where you have two drop-down lists and the option selected in the first list drives (pun completely intended) the options available in the second list. In this example, we want the user to select a make and model of an automobile.

To begin, we’ll define two selection specs for our product: “make” and “model”. The “make” spec has these options:

• Ford
• Honda
• BMW

The “model” spec has these options:

• Focus
• Taurus
• Mustang
• Civic
• Accord
• Pilot
• 3-series
• 7-series

We now go to the Edit HTML tab of the spec form and type the following:

make:
[[make]]

model:
[[model]]

The first 3 options in the model list are Ford vehicles, the next 3 are Hondas, and the last 2 are BMWs. We want the options available in this list to change on the fly based on the make selected in the first list. To set up this behavior, we go the Advanced Scripting tab and enter the following JavaScript code:

Now go back to the Preview tab, and you’ll see that the behavior of the two lists is exactly as we desired.

A few observations about the script:
- The Spec Form API methods are attached to the makeList and modelList objects automatically.
- showOptionAt takes a zero-based index. Therefore, showOptionAt(0) shows the first option, showOptionAt(1) shows the second, and so on.
- The last call to showOptionRange (corresponding to BMW) only passes one parameter (3-series). When a second parameter is omitted from this method, all options from the specified option to the end of the list are shown.

Now for a couple words of caution. For those of you familiar with HTML, you may be wondering if the various methods that refer to options by text string (as opposed to a numeric index) look up the option by value or by text. The answer is both, with priority given to value. When using these methods with specs, you’ll always want to refer to them by their text. To see why, do a View Source in your browser from the Preview tab. Scroll down until you find the SELECT elements associated with the specs. The option tags will look something like this:

As another word of caution, SELECT lists do not natively support the concept of “hiding” options, only removing them. The Spec Form API needs to do a little hocus-pocus to make the various show/hide methods work. As a result, methods of the Spec Form API take “hidden” options into account when referring to options by index. Here’s an example where the native selectedIndex property returns a different result than the getSelectedOptionIndex() Spec Form API method. Let’s say that Honda is the selected make and Civic is the selected model. This will cause the first 3 models (all Fords) to be hidden. Recall that the list always includes a visible blank option at the top (index 0).

A question posed was the viability of TIF images vs. other formats. TIFs are considerably larger than any of their counterparts because they are not lossy. JPEG images, however, are lossy, so why would I tell you to use a JPEG over a TIF? Primarily because you should edit and work from a TIF, but for inclusion into your Pageflex project, you should save your TIF as JPEG. Do not destroy your working copy of the TIF image because you should go back to that for edits to the image. Repeatedly editing a JPEG will surely lead to image degradation, so work in the non-lossy format, but always save down to JPEG for project inclusion.

I want to add that I’m not telling you JPEG images are the best print option. Obviously, if you are designing the project in Adobe tools, you should stick with the formats best suited for those tools, like PDF. If you are working from a PSD embedded in your InDesign layout, work with PDFs.

I demonstrated the difference in file sizes by taking a 70MB TIF image and saving to JPEG with 233dpi and high quality output option and removed the embedded RGB color profile. The file dropped from 70MB to 230KB in size. The print quality remained unnoticeably affected.

I found the best and most concise definition of these two formats at Wikipedia. I think these definitions support my argument above.

A little food for thought: When you purchase a stock photo library for your print jobs, what format are the images you receive?

First, we tackled the task of redesigning the default form. The previous form was very vertical. Each spec was listed individually down the page with the label directly above the control. Any product with more than 5 specs causes the page to scroll, and most user input forms have labels on the left of the control. After Release 8, the default form will be more horizontal. Here is an example:

Much of the padding and spacing was reduced to shrink the space used on the screen. Prefix, Suffix and required marker are also taken into consideration so the controls align neatly.

Secondly, we added default css definitions: SpecForm, SpecLabel, SpecControl, SpecSuffix, SpecPrefix, SpecOddRow, SpecEvenRow. These definitions exist as defaults in the global.css file, but you can override them in your theme projects. Choosing to include these styles in your theme allows you to maintain a consistent look to your spec forms that will persist to ALL of your products.

With these two changes, we hope that you are able to minimize the effort in a new product rollout. I cannot demonstrate this functionality through the usual methods until the release is completed. Rest assured, I will have a quality demo available at that time.

Next week I’ll discuss the new Product Detail Spec Form and list some new innovations that are now possible.

Regular expressions are not for the faint of heart, but what can they not do? They are the utility baseball player of software development. At the end of the post I’ll provide you with links to some resources I use as references.

For now, let’s get into the example discussion. Here is the function signature: regex([options], regular expression).

The concept is really not much different from the regular built in validators. First, I should point out that the custom regular expression validator function name is regex. You can see, as I’ve shown before, the first parameter is the optional settings. I’m defining the action and message properties in the example. The additional parameter is the regular expression string. I’ve gone with a simple example that enforces a minimum of 6 characters.

Here are some resources I use when working with regular expressions:

RegExLib.com is a decently organized community participation site for canned expressions.
Mozilla Developer Center explains the concept very nicely.
Expresso is a great tool for building and testing regular expressions.

You can read all about every validator in our API documentation which is available at http://myaccess.four51.com. As always, you can go to my demo site to find the “Spec Form API Playground” to see most of the validators in action.

Let’s start, as I often like to do, with a full sample of code for the custom function:

First, note that we have one variable spec named “CustomFunction“. It is the variable that will be provided for user input and therefore have the validation applied.

We instantiate the validator with the “custom” function. The parameters of this method differ from the other validators. The first parameter is the actual function that will fire for validation. This function must return a boolean (true/false). In the example, I’m simply checking that the value equals “The Suns” (because they will beat the Spurs!!) and returning that result. The result, true or false, triggers the correct onSuccess or onError methods, which you learned in my last post, is also overridable.

The second parameter is the familiar JSON object of optional property definitions. You can see that I’ve chosen to fire the validation onBlur and display a custom message.

Pretty straightforward, yet powerful validation tool. With this capability you can validate any scenario in your spec forms.

Next week I’ll take you through the custom regular expression capability. If you have an idea of a validator you’d like to see covered, mention it in the comments section.

In the meantime, you can read all about every validator in our API documentation which is available at http://myaccess.four51.com. As always, you can go to my demo site to find the “Spec Form API Playground” to see most of the validators in action.

The methods onSuccess and onError are actually optional parameters much like action and message. You will define them in the same JSON object, but their values will be new functions rather than strings or integers. As you should already know, in JavaScript, functions are objects too. Let’s examine an example of overriding these functions.

In the Spec Form Playground product on the demo site I have a spec named “Range”. It is the one I’ve chosen to validate a number range and also override the methods in discussion. You can see that in the JSON parameter I’ve listed onSuccess and onError right along with the action, min and max properties. For simplicity’s sake I chose to do a simple alert, but you could write a much more extensive function to suit your needs.

The default onError function is quite extensive. We’re placing exclamation point images next to the controls, changing the background color of the control plus showing error messages in mouse hovers. We tried to provide a great solution for you without your own intervention.

Next week I’ll take you through creating your own custom validations using both regular expressions and functions.

In the meantime, you can read all about every validator in our API documentation which is available at http://myaccess.four51.com. As always, you can go to my demo site to find the “Spec Form API Playground” to see most of the validators in action.

The action property is a simple string value. You have two options to choose from: onBlur or onSubmit. The primary purpose of these two options is to inform the validators when to fire its validation event.

• onBlur will cause the validation to occur immediately after the user moves the cursor out of the control. The term most commonly used is “loses focus.” This validation action provides instant feedback to the user. However, it will not keep the form from submitting. You should primarily use this as instant feedback and for suggestions on correcting.
• onSubmit will cause the validation to occur when the user clicks “Save” or causes the form to submit. This validation action lists all the errors at the top of the page. The user is then required to find the control and make the proper changes. It is most accurate in guaranteeing good information is submitted for rendering.

The message property is also a simply string value. By default, every built-in validator has a designated error message. However, it is very generic and probably does not suit your individual needs. This property allows you to customize that message per validators. For instance, if you have multiple phone validators, you can assign an unique error message to each one.

Let’s see an example of a number validator that is customizing these two properties:

Next week I’ll discuss overriding the onSuccess and onError functions, and we’ll use a different validators in our example.

In the meantime, you can read all about every validator in our API documentation which is available at http://myaccess.four51.com. As always, you can go to my demo site to find the “Spec Form API Playground.” to see most of the validators in action.

Client side validation. What does that mean? Simply put, it is the effort to validate input within the web form, rather than after the form has been posted back to the server. The Spec Form API identifies the specs that have been assigned validation and fires the validation event appropriately. Subsequently it handles the validation success or failure. If there is a failure, there are default actions that occur in the page, and when the action is assigned to the form submit the submission is canceled until all errors are cleared. Basically, if you assign validation to a spec control, the default functionality will alert the user to the error and prevent the form from being submitted.

The current default action is for an exclamation point image to load with the error appearing in a mouseover pop-up.

There is a long list of built in validators such as: phone, url, date, number. Each validators has a specific rule set. These rules are strictly set and cannot be modified. However, if you require more specific validation rules, you can write custom validators. The custom validators can take a regular expression or an actual JavaScript function.

All validators also have a wide array of optional properties, from simply changing the default error message to completely rewriting the OnError events.

In the coming weeks I’ll demonstrate how to apply particular validators and also how to override some of their default functionality.

In the meantime, you can read all about every validator in our API documentation which is available at http://myaccess.four51.com. As always, you can go to my demo site to find the “Spec Form API Playground.” to see most of the validators in action.

HTML:

This method will produce a checkbox control without any properties set. The values will be true and false. In the advanced script declaration, some optional properties are available for customization: checkedValue, uncheckedValue, displayText. I think they are named very descriptively so I won’t delve into the minutiae, but just realize that they are optional. You could certainly just declare it like so:

As with all other widgets, you have full event exposure. In the script example above, I override the onClick event and throw an alert displaying the checkbox value. Ths is a simple example, but I can imagine this coming in handy when you want the checkbox to drive visibility of other input controls. For example, the checkbox asks “Do you wish to include a mailing list?”. When clicked, a File Spec is displayed for the user to upload a mailing list.

You can go to my demo site to find the “Spec Form API Playground.” I’ve added an example of both type of Checkbox declarations to the first panel.

This widget was developed because we want our users to have a clearer decision to make regarding the selection of images in spec forms. It only makes sense that as the user is asked to choose an image they actually get to see a preview. That is easier said than done. Having blogged on this topic before, and having implemented a few of my own image preview implementations, I knew that this widget was absolutely necessary and would be very popular if done right. So, without further ado, let’s dig in.

HTML:

Advanced Script:

At first glance that looks like a lot of code and work. Trust me, it’s not really that much. In my example I’m showing you all of the available options for customizing the image selector. Plus, I put quite a few images in there so you will see the scrolling effect in the example. Let’s break the example down.

I first created a string variable named path. That’s just the path to the folder where I put all the images. I didn’t want to repeat that down the road.

The next item is the image selector instantiation. It works no differently than any other widget we provide. It simply has much more available properties. These properties are encased in {} because it is actually a JSON object. Each individual property is then listed and it’s value delimited by a colon. Every property is then delimited by a comma. Ex:

Regarding the individual properties, they are not necessary to define. Each has a default value, so if you don’t define one, the control will still work fine. The “effect” property has a few different choices. This controls an animation effect for the large preview image display. The dimension properties [width, height, thumbnailsize] control overall size of the widget. There are calculations made that scale all aspects of the widget to accommodate these properties. The style properties are descriptive enough to understand what they are controlling. highlightcolor in particular controls the border color around a thumbnail when the mouse is hovering. The rollovertext property controls the tooltip text that will pop up when the mouse hovers a thumbnail.

The images property is where you will load all the images you want available as choices. The values must be the path where the images are stored. In my example all of my images are stored in a theme folder. You can always get the url path by going to theme management in your admin interface. The property value is an array, so you’ll need to wrap all the image names in square brackets [].

Finally, we have some events that you can override as needed. All of them are listed in the help documentation. In my example I show you how to override the onChange event. This is fired after a user clicks on a thumbnail and the new value is set. These events can be handy if you need to do some validation or perform some other actions when particular images are selected.

A couple words of caution. Do not use high resolution images. The images displayed in the form are not the images that will render to your variable product. I recommend using the “Save for the Web” option in Photoshop. It’s also best to create your images with relatively similar sizes. For example, don’t have one image set at 100px x 300px, and another 500px x 100px. There is no way to determine sizing issues on the fly, so the control expects certain ratios.

You can go to my demo site to find the “Spec Form API Playground.”

Today I thought I cover some of the new features available, some of the changes made, as well as explain the new “Spec Form API Playground” product in the demo site. I’d also like to note that the new help documentation is being updated as you read this, so it will be available through MyAccess soon.

The primary new functionality in the Spec Form API is the addition of Validators. Often, as you are creating your variable products, you need better control of the input from your customers. The Validators attempt to provide that functionality. There are numerous, built-in Validators such as: required, number, email, phone, and date. Plus many more. It also provides the capability of writing your own custom Validators through a function or regular expression. If you have suggestions for additional built-in Validators, feel free to ask. The Validators also have a built in error display mechanism. When validation fails, an exclamation point image is displayed with a helpful pop-up message and the control is turned “red”.

Not previously mentioned, but previously available, is the Image Selector widget This widget is designed to present a group of thumbnails for your user to select for use in your project. There are some fancy animations attached to this and tons of hooks into the functionality.

The changes are few. In an effort to better isolate the API’s functions and attach the events to controls, we’ve refactored some things. Primarily, everything is no longer attached to the specForm variable. For instance, before you would reference a calendar widget like so: specForm.calendar.value. Now you’ll reference it straight from the spec control: spec['Calendar'].calendar.value. The only remnant is the Wizard widget. Because it is created outside the scope of a spec control it will still be accessible through the specForm variable: specForm.wizard.moveTo(2).

The API is becoming more and more robust. The examples are numerous and capabilities within widgets continue to increase. Because of this, we realized the need for a thorough testing environment so updates are ensured not to break existing work saved to your products. So we built a product that utilized every single aspect of the Spec Form API. Any changes that break existing functionality will be caught by this project and allow us to make appropriate changes before the API update is released. After the creation of this project, I realized that it would be a perfect basis for examples to discuss here in the blog. So I copied it out to the Spec Form API Playground product I’ve referenced many times before.

The gist of the product is that a wizard widget isolates different aspects while also testing the wizard’s functionality. I’ve made the source code and spec form available for download as well. It’s a good reference for those “how do I do this again?” type of questions.

In the coming weeks I’ll have thorough examples of the Image Selector and Validators.

You can go to my demo site to find the “Spec Form API Playground.”

The poster’s issue really revolves around the need for a highly specialized work flow. Specifically, they want Spending Accounts to associate with products rather than Users or Groups. While I can understand the need, the idea that a Spending Account only associates to a Product just isn’t particularly logical. Products don’t spend money, people do. Upon fully understanding this person’s need I see that they really are asking that customers use a spending account only for particular goods. It’s still a Spending Account associates to a buyer solution, but they want to restrict the good available for purchase with the Spending Account. I think we can develop a solution for this customer now that the need is fully understood.

First and foremost well defined roles must be created in the Administration interface. The products must be assigned to categories and users to groups in a logical manner. Because of the unique circumstances you can’t afford to mismatched these associations. For instance, you can’t have a box of pens product in a category for marketing collateral when it should only belong to office supplies. Same applies for user accounts. You need to be able to configure the buyer absolutely. You should be able to say “User A can use Spending Account A to purchase Product A in Category A because he belongs to Group A.” That represents a well defined and logical role.

We still have one major issue to solve: The customer should only be able to purchase certain products using the Spending Account. How is this configured in Four51? The simple answer is that it can’t be configured. We have to create this logic outside the application through the use of Web Services.

I’ve covered the topic on previous blog posts so I won’t go into the technical implementation. I will simply discuss the solution they can provide in this circumstance.

The most useful web service for this scenario is the ValidateAddToOrder. We must ensure that the shopping cart does not contain a mixture of products by payment method. For instance, a box of pens cannot be purchased by spending account so we cannot allow them to be added to the cart if business cards have already been added. The business cards are eligible for Spending Account payment, the box of pens are not. Utilizing this web service we can examine the current shopping cart contents [Line Items] to determine the validity of the request to add the product to the order. I would return a message to the user that their action is not allowed, but they can create an additional shopping cart to purchase this product.

I’d also utilize the ValidateOrder and ValidateBilling web services to ensure the proper products are purchased with the proper methods. There is no mechanism that will eliminate the Spending Account payment method based on the products in the cart. So if the customer attempts to purchase that box of pens with their spending account these web services can catch that and deny the action.

I hope I’ve demonstrated the process of thinking through a Four51 solution and utilizing all the available resources at my disposal.

This particular product is a jersey selection product. We’ll present the user with two options: Team, Type. Team is comprised of several different football teams in the NFL. The Type will be a choice of jersey style. For example, Jacksonville Jaguars Road Jersey. We need to present a preview of this choice in our variable document, and we also need to save the variant with a code that informs us what jersey was selected.

I’ll begin by creating a Pageflex project with three variable: Image (image script), Team (plain text), Type (plain text). I’ll be storing images of each jersey combination in the images folder. The script that determines the image selection is not the focus of this demonstration so I won’t display that, but you can download the project files if you are interested.

The project has been uploaded to our product, and the variable have been imported. Next, I’ll create a new variable named Code. It will be a Text type and no other properties are important. Now I’ll add the Code variable as the Variant Identifier. Finally, we’ll move into the spec form and make all this work together.

We’re working off a basic table of information that maps teams and types to codes.

• Dallas Cowboys Road = DALRD-989
• Dallas Cowboys Home = DALHM-789
• Dallas Cowboys Special = DALSP-189
• Green Bay Packers Road = GBYRD-946
• Green Bay Packers Home = GBYHM-846
• Green Bay Packers Special = GBYSP-146
• Pittsburgh Steelers Road = PITRD-925
• Pittsburgh Steelers Home = PITHM-825
• Pittsburgh Steelers Special = PITSP-125

The HTML will be comprised of two dropdowns for the teams and the type. Hidden on the form will be the actual variables that we need to make the project work, as well as the Code variable for the Variant Identifier.

Notice the two select elements are not variable specs. They do not need to be and in order to work with display text and values we have to use the base html elements.

Lastly, our Advanced Script will perform all the work under the hood.

First, I use the hide() method to hide all the controls that are working under the hood. Then I’ll define three JSON objects that store the values we want to display to the user: jerseys, types, codes. I’ll then get() the two select elements and use the addOptions() function to populate them with the JSON values (note: the addOptions() takes a JSON object as a parameter. It will serialize the values and insert them into the element for you). At this stage I have everything ready for customer input.

Now I’ll handle the user selections. Again, I get() the select elements and then bind a function to their “onchange” event. The function simply concatenates the values selected to create one value that matches a value in the codes JSON object. It is returned and setText() places the code in the Code variable.

This is just one example of how to accomplish this need. There are a number of different ways to go about solving this requirement. Hopefully in this demonstration you will understand some concepts that will help you develop your own solutions.

As always you can go to my demo site to see this solution in action, as well as download the project files.

For the skilled JavaScript developer, the help file should be more than enough to get started. The API functions are called using the same syntax as any JavaScript method. Our goal in supplying users with this skill set revolves around exposing a cleaner environment for development as well as supplying some handy shortcut functions that are consistent headaches. For example, any script written in the Advanced Scripting tab is automatically fired at the appropriate sequence in the page creation and loading. I won’t delve into all the available options, but this particular type of person will see the many benefits of the Spec Form API.

The newly initiated have the option of using the help file examples and working within a narrow scope of the API framework. We’ve attempted to design each feature to be used with minimal work. In fact, most are capable of working simply by defining a class name.

If you are inclined to dig into learning JavaScript, I can list you a few resources that would be very beneficial:

• Mozilla’s Reintroduction to JavaScript is outstanding
• You will want to get Firebug to help in debugging
• Douglas Crockford, Yahoo’s JavaScript Evangelist, has a great series of videos
• The best book on JavaScript comes from O’Reilly

Learning JavaScript takes time and patience, but the journey is a lot of fun. Once you have a decent grasp you can also utilize JavaScript within your Pageflex projects.

First, let’s define the idea of Localization. Localization is the process of adapting a software program or website to the language and culture of a particular region. The ability for an application to support multiple languages is actually a daunting task. For instance, the Four51 application currently supports four languages:

1. English-US
2. English-UK
3. Dutch
4. Portuguese

This is accomplished by storing every single instance of text on the site in a resource file. These resource files are submitted to a company called Translations.com that specializes in translations. They meticulously translate every single word in those resource files and keep track of changes from one application release to the next. The end result is seamless localization by simply “flipping a switch,” allowing users of those languages to read and checkout of the application in their local date formats and currencies.

The concept of localization, or language support, in Pageflex Studio is actually quite different. Studio is a document creation application, meaning that the content is created by the user. Under this concept, the document creator is responsible for the translation. The responsibility of language support falls under the purview of the user. So, what does the language support actually do? Two things: uses a language library to determine hyphenation rules, and the language’s character set to calculate dimensions for features like wrapping and copy fitting. Essentially, as long as the font chosen supports the full character set of almost any language, the Studio application will render the text precisely².

Secondly, let’s discuss how a PC handles localization. This is an important aspect of localization because a user must interact with Four51 within the rules set forth in their specific locale. The important group set contains rules for keyboard layouts and fonts. A Portuguese speaking person uses a set of characters that may not exist as simple keys on an English speaking person’s keyboard. So, your operating system must conform to the supported language and respond to the differences. Your browser operates under these same rules, therefore when a Portuguese speaking person is asked to input text into a field it is actually their operating system’s localization rules that are governing the input, not the Four51 or Pageflex application. At no time is any attempt to translate the input performed by the Four51 or Pageflex application. The applications ingest the input and render it to the printable document using the rules you define in the template.

To help visualize the localization ability of Four51 and Pageflex, I’ve set up a project on the demo site that works with both Dutch and Portuguese. I chose to demonstrate the support for both languages in one project so that you can see the independent nature of the language from the applications. The example company’s locale is US-English, one template file is Portuguese, and the other is Dutch. All three languages are working within the same context.

I also created default values for each language. In English the value reads, “Displayed as a label on the Billing stage of the check out process when Purchase Orders are allowed.” This is an actual value in our current resource files. I chose this sentence because the hyphenation rules are enforced for each language. When rendering the example you will see hyphens in the appropriate places. Actually, I just hope they are in the appropriate places because I don’t speak these languages, much less understand proper hyphen placement. I’ll trust that Pageflex has provided an accurate library for these languages.

The specifics for the project setup are actually quite simple. I used the font MetaBold-Roman for both languages. MetaBold-Roman is already installed on the Four51 servers. This is an important note because the key to supporting character sets in other languages depends on the font. The font you choose for your template must contain these characters or they will not render to the printable document. In each template file I set the Default Langauge to the specific language. This is all it took to create the template files.

Pageflex Studio fully supports all the languages in the Paragraph Properties’ language drop-down list. With two exceptions, “full support” refers to composition, hyphenation, and spell-checking. This applies to:

• Danish
• English-US, UK
• French
• German
• Italian
• Norwegian
• Portuguese
• Spanish
• Swedish

The two exceptions are Japanese and Chinese, which, though also fully composed, require no hyphenation or spell-checking. In addition, Pageflex can compose over 60 other languages, and as a general rule, these are languages that are read left to right and top to bottom.

To see the different languages, I set up the proof and production outputs to use different template files. Proof renders the Dutch example, while Production renders the Portuguese example. I encourage you to create a project utilizing other languages, such as Russian, to perform your own language support tests.

You can go to my demo site and find the “Localization” product to see this example in action and download the project files.

^{1. There are some instances which Pageflex does not support hyphenation or ligatures. Generally these are limited to languages that do not have hyphenation (Japanese, etc..), or more generally languages that are read right-to-left (Arabic, Greek, Hebrew, etc..).}

The time selection control is designed to help you enforce standard formatting for time input in your projects. It’s often a struggle ensuring your customers adhere to a defined format, so we’ll eliminate that concern by controlling their action.

We have two ways to declare this control. Let’s look at the simplified example:

HTML Example (need one TextSpec Control):

Very simple and straightforward. The key is to wrap your TextSpec in a span element. The class designation tells the Spec Form API to create and attach the elements that comprise the time control.

Now, the Advanced Scripting implementation (need one TextSpec Control):

HTML:

Advanced Script:

As you can see, this implementation isn’t much more complicated. The focus is on the optional parameter: increment. That property is exposed to allow you to customize the minute list. For example, the increment of 15 would have 00, 15, 30, 45 as choices in the drop down.

Under the hood, the TextSpec control will receive the selected values formatted with the following mask: HH:MM am. Additionally, the stored value will persist. When the spec form will render valid time will select the appropriate values for the time control.

You can go to my demo site and find the “Spec Form API Playground” product to see this example in action.

HTML example

Simply two Spec Controls of text type named Calendar and HiddenDate. In a production environment I’d hide the HiddenDate control from the user, but for this demonstration purpose we’ll keep it visible.

Advanced Script example:

This example is doing two things. First, we want to be sure