Anyone that has written JavaScript knows how difficult it can be making that code work in every browser. Debugging your code in those browsers was painful without tools like Firebug. Still, all too often you’d get everything working really well only to find that IE wasn’t happy with your work. I’d say this has caused me to go bald, but that happened way too long ago.

The new IE Developer Tools are simply amazing. They’ve incorporated nearly everything that Firebug offered (it is missing hover over variables) and I think they’ve improved on the user interface. Plus, Firebug development has slacked in keeping up with Firefox upgrades and still has some very annoying bugs. I am contemplating switching over to IE8 for my primary JavaScript development environment and I honestly am surprised I’m writing that.

I urge each of you that follow this section of the blog to try out the new tools for yourself.

I want to go beyond the simple “You can use it as a default value” in a spec form. I think that’s understood because you’ve always been able to use those default value tokens before. I’d like to take a different path. I will diagram how you can use custom user fields and tokens to display contact information for their assigned customer service representative on your Home Page.

I’ll first create a new user field named “Rep” and make it a selection type. I’ll set it to display to the user and add some choices for the dropdown and save. Then I’ll assign it to the entire company.

Now, I’ll put the contact information on the home page through the Buyer Site Customization Home Page template. The home page customization looks like this:

[[CustomMessage]]
[[Rep]]


[[Catalog]]
[[Messages]]
[[Orders]]

What I’ve done first is create a span element that will hold the Rep token value. Giving the span an ID property allows me to reference it in a script easily. I then added a div element to hold the result of the script. It will be what is displayed on the page. Then I add the script. I created a JSON object that holds a key value pair that matches the Customer Service reps in the custom user field with phone numbers. Just a simple example. At this point I declare a variable, “rep”. That variable value points to the span element I created to hold the token. Referencing the innerHTML property returns the value the token renders on the page. Finally, I take the token value, look up the pair in the JSON data object, and write it out to the “ContactInfo” div element so it will display on the Home page.

This example doesn’t hold any real world value. I just want to demonstrate to you how, with some imagination, you can do so many things with the information available to you in the new Custom User Fields. As always, you can go to my demo site play with the example I documented today.

If you have any questions about this blog post, please join us on the forum.

I’ve created a demo project that allows for width and height inputs. This is just one example of the 4 types of document actions.

There are 4 different page resize document actions: ResizePage, ResizeWidth, ResizeHeight, ResizePageByPercentage. The demo focuses on the ResizePage action, but the principles are the same.

The first thing to consider is that these actions require proper measurement values. For example, you can define a page size with the following values: Width = 5in, Height = 3in. If the input is not in the proper measurement format an error will be thrown. That’s why the demo uses a dropdown selection. That makes enforcement of those measurement formats easy.

Another major factor to consider is that these actions ONLY resize the page. Not the objects on the page. If that’s an issue you will have to ensure you’ve set all your project elements to flex appropriately. In the demo each element has many flex and copy fit rules applied. It will render correctly with any dimensions that are chosen.

I’ll repeat that these actions are most likely never the best solution for your products. They have a great probability of formatting your output incorrectly and without warning. The more content on a document the more likely it is there will be problems. I almost always recommend using multiple projects and or variable documents.

I have set up a demo product named “Documents Actions ResizePage”. Go to the site to see it in action, and also download the project files I created.

Using the published document action from Pageflex, I changed some of the functionality and imported it into the Four51 Document Actions library. The goal was to make it more flexible and targeted, as well as work more similarly to the existing actions in the library. Due to the unique nature of this document action I thought a blog post was in order. Of course, you should use the wiki as a reference guide.

What does this document action actually do? It’s actually pretty simple. First it gathers the size (width and height) of the image and it’s parent (area template). It then compares those sizes to determine the greater difference between the two ratios. If the height ratio is larger then the image will be scaled to the height of the area template, and vice versa for when the width is greater. This scaling will obviously leave the image larger than the area template in which it’s contained, but this is desired. The area template will crop the excess image area, leaving the entire area template filled with the area the image fits.

The anchor point property of the image controls how the image will be cropped. If the anchor point is set to Center/Middle it will be cropped evenly on all sides. If the anchor point is set to Left/Top the image will be cropped on the right and bottom.

Special recognition for this solution goes to Pageflex. It was their idea and source code that forms the basis for this offering.

This document action example can be viewed and downloaded at the demo site. The product is named “Documents Actions Scale Image To Fill”.

I’ll use a combination of 2 different document actions (ReplaceText, Superscript). The project requires only one variable: Text. Text must be set as Formatted Text kind.

First, I’ll create the ReplaceText action. This action does precisely what the name suggests. It takes a character set to find, and when found replaces that text with another set of characters. In this case I’m looking for “NFL” so that I can replace it with NFL™. Here is the document action definition:

Method: ReplaceText
Arguments:
SpecName (contstant) = Text
OldCharacter (Constant) = NFL
NewCharacters (constant) = NFL™

Secondly, I’ll demonstrate the use of the Superscript action. While it’s not necessary in this example I wanted to show how it can be used, even in conjunction with another document action. Here is the document action definition:

Method: Superscript
Arguments:
SpecName (constant) = Text
Character (constant) = ™

Pretty simple example, but one that I think translates into real world project needs. I suggest you follow this up by reading on the GetPositionIndex action as well as Suffix and Prefix. They are closely related to the actions discussed in this post.

This document action chaining example can be views and downloaded at the demo site. The product is named “Documents Actions Calculations”.

The formula is quite simple: (x * y) / z = Sum. So we have three numerators and two calculations to perform to reach our sum. This requires we use 2 document actions: Multiply and Divide. The key to accuracy is the order in which we list our document actions.

First, we’ll create the Multiply action. Take note that the SpecName argument is a constant type. We are assigning a value to a variable, so we must type the name of that variable as the argument value.

Method: Mutiply
Arguments:
NumberA (variable) =
NumberB (variable) =
SpecName (constant) = _x_y

Lastly, we’ll take the sum of the multiple operation and Divide it by the z value. Notice in this action we are using the value assigned to the _x_y variable by referring to the variable.

Method: Divide
Arguments:
NumberA (variable) = <_x_y>
NumberB (variable) =
SpecName (constant) = Sum

And we’re done. You can put the Sum variable anywhere in your template file and the calculated value will print. I didn’t demonstrate the formatting capabilities, but you should play with them. They are quite powerful.

This document action chaining example can be viewed and downloaded at the demo site. The product is named “Documents Actions Calculations“.

The security bar also displays Four51 and the trusted VeriSign brand, which help assure your customers they are on the intended Web site and that their transactions are secure.

Additional information on SSL and Extended Validation can be found from Verisign at http://www.verisign.com/ssl/ssl-information-center/ie7-ssl-security/

Neither Lynn Anderson nor I ever promised you a rose garden. What does that have to do with anything, you might ask. It reminds me of debates about technology upgrades. When encouraged to upgrade to the latest version of something, we (me included) are at times tempted to push back and say: I don’t want to upgrade. What I have works fine. The new version will undoubtedly have stability issues. And all my employees are trained on the current version, and now you’re setting us back. And so on. Ad nauseum.

Well, no one ever promised that your interface would remain the same forever. DOS gave way to Windows. Progress isn’t without setbacks, but if you choose technology partners wisely, real progress over time is what you’ll get. That’s what you were promised. Protecting your business data, not the interface. Taking advantage of new features means new learning.

So, here is something to keep in mind when debating about upgrading to Pageflex 6. The Four51 application support team has upgraded to Pageflex 6 on all our machines. This means that if you require us to open a product we will not be able to upload any changes that we make to it unless you are also using Pageflex 6. Once a project has been saved in Pageflex 6 you will not be able to open it again in an older version.

Help support help you by upgrading. Plus Pageflex 6 has a lot of cool new features!  Check out a recording of the demo I gave on September 25th on the knowledgebase to learn more about it.

Who is your friend? “Add” is your friend!

Thank you.

-Mike & Jim, with all due respect to Lynn

Today’s demo of SelectImage will combine capabilities of some spec form scripting along with the document action. I’m trying to cover a scenario I think is widely used throughout Four51.

The idea is to present a dropdown of choices to the user. Once a choice is made an in-form preview of the image will be displayed. Once the user saves the variant the SelectImage document action will retrieve the correct image for rendering. Utilizing the document action eliminates the need to create a cumbersome rule, and I’ll show you how to set the project up in a way that allows you to quickly add new options without having to edit your project and template files.

Let’s start with the template file. I’m going to keep the demo simple by only placing a new image element in the center of the template. Then, using the element properties I’m going to give it a name: Jersey. The name property is available in the “Info” tab of the properties window.

Next, I want to create two variables in the project file: ImageChoice, Images. Both variables are constant plain text types.

The last task within the project files is to create the jobs and define the document action. I’ll only cover the arguments because you should be familiar with adding a document action by now. The SelectImage action has 4 arguments: ImageElement, Case, SourceArray, ErrorMessage.

• The ImageElement is looking for the name of the element that will get the image assignment. Remember above that we named the element “Jersey”, so we’ll just keep the value type Constant and type “Jersey” into the vaue field.
• The Case argument is the value indicator. Meaning that the selection value should be applied to this argument. In our demo that value is the ImageChoice variable, so I set the Value Type to Variable and then select the variable from the list.
• The SourceArray is the array of image choices. They are essentially key value pairs. There is a key (dropdown text) and a value (image) in each pair. The keys should exist in our dropdown options and the values should match images in the project image folder. I’m going to choose Variable Value Type and select the Images variable from the list as the argument value. This is what will allow you to add new options without needing to edit your project files.

Now that our project is complete and we’ve created the product on Four51, let’s set up the spec form and script.

First, the variable import for ImageChoice will be defaulted as text, but we want to make it a selection and add our choices: Green Bay, Indianapolis, Tennessee. For ease of reading I’m setting the Image variable to have 10 lines and 5000 characters. I’m also setting the default to the SourceArray value. This is the key to the update without touching the project file.
{Green Bay=gbhome.jpg}
{Indianapolis=indyhome.jpg}
{Tennessee=tenhome.jpg}

The spec form has little change to the default. I’m basically adding an image html element (id = preview) for the in-form preview:

ImageChoice		[[ImageChoice]]
Images		[[Images]]


Lastly, we’ll write our script for previewing the image. You’ve seen this before so I won’t go into great detail:


var preview = get('preview');
var image_choice = spec['ImageChoice'];
var path = "http://www.four51.com/Themes/Custom/de891832-01b5-4c5d-84da-b4f85e394864/demo/jerseys/";

var images = {
"Green Bay": "gbhome.jpg",
"Indianapolis": "indyhome.gif",
"Tennessee": "tenhome.jpg"
}

function Display() {
preview.imgSrc(path + images[image_choice.selectedText()]);
}

image_choice.onchange = Display;
image_choice.removeOption(0);
// Normally I'd hide this variable, but I'm leaving it visible for the demo.
//spec['Images'].hide();
Display();


You can see the comment regarding leaving the Images variable visible. I wouldn’t want a customer to see this obviously, but I’m leaving it for the demo.

Now that we’re done setting up the product you can continually add new image options by simply updating the options in the two variable. Your project is equipped to handle that without intervention.

I have set up a demo product named “Documents Actions Select Image“. Go to the site to see it in action, and also download the project files I created.

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:
Just create a span element and assign a class name corresponding to the list you want. The default usage displays the full name of the item, but records the abbreviation as the value. For example, Minnesota = MN.

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.
spec['States'].statedropdown({displayType: "abbr"});
spec['States'].statedropdown.onChange = function() {
alert('You chose: ' + this.selectedText() + ' and the value is: ' + this.selectedValue());
} This code example defines the drop down as a list of states, but the display is the abbreviation rather than the full name. Additionally, whenever an item in chosen in the drop down, the browser will pop up an alert showing what was chosen.

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:

spec['Comma'].hide()

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.
spec['Phone'].mask('999.999.9999');
That’s all there is to it. That pattern forces a user to enter only numbers, and when they reach a delimiter the “.” will already be there and will not be editable. The cursor will skip over the “.” so the user can simply continue typing. When the phone variable (textbox) has focus “___.___.____” will be displayed.

Here is a snippet of all the examples on the demo product.
spec['Date'].mask('99/99/9999');
spec['Cost'].mask('$99.99');
spec['Phone'].mask('999.999.9999 x9999', "*");
spec['SSN'].mask('999-999-9999', '#');
The syntax for the Spec Form API follows this convention: spec[variable].mask(pattern, placeholder). The placeholder is the character that displays in the space designated for input. In the phone example, I specify an “*” as the placeholder. The user is then presented with “***.***.**** x****” for input. The default placeholder is the underscore “_”, and this parameter is optional.

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:

// assign specs to variables to make them easier to reference later in the script
var makeList = spec['make'];
var modelList = spec['model'];

// also call the function immediately to initialize the form
refreshModels();

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:

Ford

The values associated with options are encrypted identifiers generated by the Four51 application. Referring to spec options by value not only makes your script difficult to read, but is pretty much guaranteed to break the script entirely because these encrypted values change with each user session.

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

modelList.selectedIndex // native API doesn't know about "hidden" options, so this returns 1.
modelList.getSelectedOptionIndex() // Spec Form API knows about "hidden" options, so this returns 4.

I hope this article gives you a good starting point to begin turbo-charging your own drop-down lists. As always, your questions and feedback are welcomed and appreciated.

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

spec['Department'].regex({
action: "onBlur",
message: "Minimum of 6 characters required"
}, "(?=^.{6,100}$).*$");

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:

spec['CustomFunction'].custom(
function() {
var result = spec['CustomFunction'].value == 'The Suns';
return result;
},
{action: 'onBlur', message: 'You must type (The Suns) because they are the best team in the NBA'}
);

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.


spec['Range'].range({
action: 'onBlur',
min: 5,
max: 50,
onSuccess: function() { alert('Your entry is accurate'); },
onError: function() { alert('Your entry is not right, must be between 5 and 50'); }
});


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:
spec['Quantity'].number({
action: "onBlur",
message: "Please enter a quantity before continuing…"});
You can see that these properties are like most of all other properties we’ve seen before. It’s a basic JSON object. Simply wrap the key value pares between curly braces {} and delimit with a comma. Remember that there are default values. If you choose not to include these properties your validators will still work. They are optional 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:
[[CheckBox]]
Advanced Script:
spec['CheckBox'].checkbox({
checkedValue: 'I am checked',
uncheckedValue: 'I am not checked',
displayText: 'Check me to see my value'
});

spec['CheckBox'].checkbox.onClick = function() {
alert(this.value());
};
First, you see that we just include the Spec token in the HTML. If you chose, you could also wrap the token in a span tag with a class value of “CheckBox”.

[[CheckBoxClass]]

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: spec['CheckBox'].checkbox();

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: [[Image]]

Advanced Script:

var path = "/Themes/Custom/de891832-01b5-4c5d-84da-b4f85e394864/Demo/Jerseys/";
spec['Image'].imageSelector({
effect: 'fadeIn',
bordercolor: "red",
width: 460,
height: 200,
thumbnailsize: 40,
bgcolor: "#fff",
bordercolor: "#000",
highlightcolor: "#ff0",
rollovertext: "Click this to choose jersey",
images: [path + 'dalhome.jpg',
path + 'dalroad.jpg',
path + 'dalthrow.jpg',
path + 'gbhome.jpg',
path + 'gbroad.jpg',
path + 'gbthrow.jpg',
path + 'indyhome.gif',
path + 'indyroad.gif',
path + 'indythrow.jpg',
path + 'jaxhome.jpg',
path + 'jaxroad.jpg',
path + 'jaxthrow.jpg',
path + 'nehome.jpg',
path + 'neroad.jpg',
path + 'nethrow.jpg',
path + 'nyhome.jpg',
path + 'nyroad.jpg',
path + 'nythrow.jpg',
path + 'pithome.jpg',
path + 'pitroad.jpg',
path + 'pitthrow.jpg',
path + 'sdhome.jpg',
path + 'sdroad.jpg',
path + 'sdthrow.jpg',
path + 'seahome.jpg',
path + 'searoad.jpg',
path + 'seathrow.gif',
path + 'tbhome.jpg',
path + 'tbroad.jpg',
path + 'tbthrow.jpg',
path + 'tenhome.jpg',
path + 'tenroad.jpg',
path + 'tenthrow.jpg',
path + 'washome.jpg',
path + 'wasroad.jpg',
path + 'wasthrow.jpg',
]});

spec['Image'].imageSelector.onChange = function() {
alert('Thank you for choosing me! ' + this.image());
return true;
}


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: { effect: 'fadeIn', width: 460 }

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.

[[Code]]
Team:


[[Team]]

Type:


[[Type]]


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.

spec['Code'].hide();
spec['Team'].hide();
spec['Type'].hide();

get('teamlist').selectOption(0);
get('typelist').selectOption(0);


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

[[Time]]

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: [[Time]]

Advanced Script: spec['Time'].time({increment: 15});

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
Date:  [[Calendar]][[HiddenDate]]


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:
spec['Calendar'].calendar();

specForm.calendar.onChange = function() {
var now = new Date();
if (specForm.calendar.FullDate() < now) {
alert('You must select a date in the future.');
spec['HiddenDate'].setText('');
return false;
}
else {
spec['HiddenDate'].setText(specForm.calendar.DayOfWeek());
return true;
}
}

This example is doing two things. First, we want to be sure the user is selecting a date in the future. Secondly, we really want to print the day of the week on the print document so we'll set an additional spec to that value. Let's breakdown how we are doing this.

We will perform our tasks once data has been selected from the calendar pop up, so we need to attach a new function when a date is selected specForm.calendar.onChange = function() { }. The first thing we need to do in this function is create a Date object so we have current date and time for comparison. var now = new Date(); Now we'll check that it's a future date by comparing our new Date object to the FullDate() property of the the calendar. if (specForm.calendar.FullDate() < now) If it's in the past we'll inform the user of her mistake and reset our hidden spec control to an empty string.

alert('You must select a date in the future.');
spec['HiddenDate'].setText('');

If the date selected is valid we'll store the DayOfWeek() property in the hidden spec control spec['HiddenDate'].setText(specForm.calendar.DayOfWeek());

Now we have the day of the week available to print on our variable document.

I've demonstrated how to create a calendar control on your spec form, and a few properties available to work with (DayOfWeek, FullDate). There are more that I didn't cover, but you should know about. Simply get the Spec Form API documentation and check them out. And as always, you can go to my demo site and find the "Spec Form API Playground" product to see this example in action.

Example HTML:
Meal:  [[Meals]] and Menu: [[Menu]]

There are two selection specs: Meals and Menu. I added the options: “Breakfast”, “Lunch”, and “Dinner” in the spec properties. They will always be our choices. For now the Menu spec does not have options.

Example Advanced Script:
spec['Menu'].hide();

if (this.selectedText() != "")
spec['Menu'].show();
else
spec['Menu'].hide();
}

Let’s breakdown the advanced script:

First you see that we will simply hide the Menu spec. Every time the page loads it will be hidden by default. We don’t want to show it until a Meal has been selected because we want to give them particular options based on that choice.

The meat and potatoes of this example begins with the assignment of a function to the onchange event of the Meals spec. Like I said, we want to give the user particular options based on their Meal choice. We define those options in the JSON object choices. To read more on JSON check out this introduction. In the choices object I am defining the three meal objects and assigning an array of values as the menu choices. For example, one object in the choices JSON object is defined as such: "Breakfast": [""Pancakes", "Waffles", "Omelet"]

This just gives us an object to work with. We must figure out which of the items to use and we will base that on the Meal selection. First, we will remove all of the items from the Menu spec by calling “removeAllOptions()” which is a method in the Spec Form API. Then we will check on the selection by getting the “selectedText()” of the Menu spec. Based on the value of the selectedText() we will use the choices JSON object to add the options by calling the “addOptions()” function in the Spec Form API. Notice that we can reference the Menu choices with simple dot notation. This is the awesome aspect of JSON.

Lastly, we show or hide the Menu spec based on whether or not a Meal has been chosen.

In this demonstration I introduced you to several new functions of the Spec Form API: removeAllOptions(), selectedText() and addOptions(). Very powerful, but easy to use methods for any Selection Spec Control. There are more that I didn’t cover, but you should understand. Simply get the Spec Form API documentation and check them out. And as always, you can go to my demo site and find the “Spec Form API Playground” product to see this example in action.

First the HTML (3 variable specs created named: AreaCode, Prefix, Number):
Phone Number: [[AreaCode]].[[Prefix]].[[Number]]

Very simple and straight forward. One important note: You must set the max length property of each variable spec to the number of characters you want the user to enter before moving to the next field.

Now for the Advanced Script:

spec['AreaCode'].autoTab("Prefix");
spec['Prefix'].autoTab("Number");

So, how does it work? Very simply, when you call the autoTab function the Spec Form API attaches a function that first compares the number of characters in the field to the max length property of that field. If they are equal, it then sets cursor focus on the field you name in the function argument.

A lot of people like this usability feature but don’t know how to implement it for their spec forms. Hopefully this example makes it simpler. As usual you can go to my demo site and see this in action in the “Spec Form API Playground” product.

The scenario I’m covering is simple: When the user makes a selection from the drop down show a particular item in the form.

Here is the HTML markup:

The [[RadioList]] is a selection spec control that contains these options: This, That, The Other Thing. Based on the user selection we will display one of the three “div” elements in the HTML.

Now let’s examine the advanced script:

function HideAll() {
get("thisChoice").hide();
get("thatChoice").hide();
get("otherChoice").hide();
}

HideAll();


Three different things are happening here. First, I created a function named HideAll() that simply gets each of the div elements and calls the Hide() API function. This ensures we are hiding all of them when the page initially loads. Jumping to the end of the script you’ll see that I call the HideAll() function. I’m doing that last to emphasize that the function must be created before you can call it. The real action occurs in the spec['Selection'] onchange event.

We want to declare a function to fire on that event and the syntax to do this is: spec['Selection'].onchange = function() { } Whenever the drop down is clicked the onchange event is fired, and that’s when we want to decide which information to display to them.

Within this function we first want to call the HideAll() function to reset the display of all the elements. Without this we would end up having more than on option displayed at a time. Then we evaluate the selectedIndex of the drop down list in a switch statement. The selectedIndex property contains the numbered item in the list currently selected. We check for that property in each case and perform the appropriate action. For example, if “This” is chosen in the drop down we want to show the div element with the id “thisChoice”. We do that with the get() API function which I covered in a previous post. Of course the “break;” signals the code to exit the switch statement.

I think this demonstration covers a widely desired functional aspect of Spec Forms on the Four51 application. Utilizing the Spec Form API makes this process very easy to accommodate.

As previously mentioned I’m demonstrating the Spec Form API examples in the “Spec Form API Playground” product on my demo site.

The first example will be a simple checkbox click displays a textbox. Here’s the HTML:

You can see that I hard-coded an HTML checkbox element and included a spec control named “ToggleTest”. I did not set the “checked” property to “checked” because I want the user to click the box to expose the “ToggleTest” control. We are controlling when it’s visible through the advanced script:


spec['ToggleTest'].hide();

get('check').onclick = function() {
spec['ToggleTest'].toggle();
}


The first line simply tells the ToggleTest control to become hidden.

In the past you’ll remember that I documented the “InitializeSpecForm” function and told you to put any code you wanted to run on page load there. With the Advanced Scripting tab we automatically handle that for you know. You simply need to put the code in the tab and it will run on page load. This is an important note because the order of the page load is complicated and if not followed properly will simply result in JavaScript errors.

Next, I use the “get” function to find the HTML checkbox with the id: “check”. I want to toggle the visibility of the “ToggleTest” when the user clicks the checkbox so I bind the Spec Form API function “toggle()” to the onclick event. That section of code basically says “When the “check” checkbox is clicked peform this function: spec['ToggleTest].toggle();The toggle() function checks the current state of the referenced element and simply changes it to the other state. An easy analogy is a light switch.

I’ve put a new product on the demo site named “Spec Form API Playground.” I have this example there, and in the future I’ll continue to expand on that product with further examples. Next week I’ll show you howto use a radiobutton list to show or hide a choice between several different elements based on the selection of the user.

One of the great aspects of this widget is that you do not have to type a single character of code. Not only no actual coding, but the HTML markup is even WAY simpler. Let’s demonstrate.

I created 3 text spec controls named: Input1, Input2 and Input3. Then in the HTML markup I put the following:

If you compare this HTML markup to the previous blog demonstration you’ll see a remarkable difference. This is literally all you have to do. Of course you will usually want to put more information in the individual panels/div elements.

The wizard basically takes the first “div” element with a class name of “Wizard”, then looks within that element for all other “div” elements. Each of the found elements becomes a “panel” in the wizard. The widget automatically injects a border around the wizard as well as the navigation buttons for stepping through the panels.

Now, we didn’t stop there. We thought some of you savvy users might want to actually interact with the wizard programmatically and didn’t want to leave you out. We built in several events that you can override and write specific code against. Each of these events is documented in the help file, but I’ll give you an example of one usage.

Say you want to put special emphasis on moving from panel to panel by prompting the user to acknowledge they are ready to move on. You can simply override the Wizard’s onBeforeMoveForward event like so:

specForm.wizard.onBeforeMoveForward = function() {
return confirm('Are you sure you want to move on?');
}

This will prompt the user with a confirmation popup window asking them if they are sure they want to continue. Because the event must return true or false the result of the user interaction will determine whether or not the wizard advances to the next panel.

If any of that confused you, don’t let it discourage your use of the Wizard. The events are supplemental to the actual Wizard, and if completely ignored will have no bearing on its functionality.

As always, I have a demo of this solution on my demo site. I simply reworked the existing Wizard Spec Form example product. Feel free to ask questions in the comments below.

API is best defined as:

The set of procedure calls that communicates with a linkable procedure library. An interface to software libraries. An API can consist of classes, function calls, subroutine calls, descriptive tags, etc.

In our approach to development of this feature, our goal was to simplify the ability to leverage traditional JavaScript capabilities in the spec form. One of the most sought after services requested of us is to create more functional spec forms. Many of my previous posts revolved around spec form usability, and most of those solutions were accomplished through JavaScript coding. We realize that this is a skill set that many of our customers do not possess, so we went about attempting to reduce the need to understand programming while still leveraging the power of JavaScript.

Today I’ll give an example that will hopefully demonstrate how we’ve simplified some aspects.

In many examples from this blog you were introduced to accessing spec controls with the following syntax: spec['SpecName']. This is actually an array named “spec” of all the spec controls on the page, and we’ve been accessing individual controls by referring to the array index by name (['SpecName']). This was a shortcut provided to make it simpler to program against those controls. However, if you had placed controls not included as a spec control, such as a checkbox, you were not able to use the array to access it. You were required to use the document.getElementById() function in JavaScript. I imagine this was confusing to someone trying to learn JavaScript.

In our Spec Form API we have a simple method named “get()“. You can use this method to retrieve any control in the spec form by name. For example, let’s say you have spec form with a spec control you’ve named “InputName” and a regular HTML checkbox control with the ID “IncludeTitle” With the “get()” method you can access both using the following: get("InputName")get("IncludeTitle")

This is just the beginning of our discussion on the Spec Form API. The “get()” method is a fundamental aspect you will utilize in almost all of your advanced scripts. There are many more. Included in the API are feature sets called “plug-ins”. Next week I’ll discuss the Wizard plug-in.

For further understanding of this feature, visit Access Four51 and download the help file. This file documents all of the current methods and plug-ins. It includes examples of each and signature definitions.

We are taking the approach that this is will be a continual work in progress. Post comments here if you have ideas for new plug-ins or methods that will help us continue to improve the new, powerful feature.

Here’s the markup:

Pay special attention to the style classes named: black_overlay and white_content. These two styles become the mouseover toggle and produce the opacity effects in the product area. Notice in particular the z-index property. This property guarantees that the opaque effect will overlay the contents.

The effect is toggled in the table cell’s onmouseover and onmouseout events: I chose to set the ID property with the [[ProductID]] token and precede this with “td”. This ensures uniqueness. The new property we have not discussed previously is “className”. Very simply, it sets the class on the element referenced. Much easier and more concise than trying to set each individual property we want to alter.

Remember that I recommend you put any styles in your custom theme. If you copy and paste this example into your Product List Customization, the data will be repeated for every product and the page size will increase exponentially. Hopefully these examples spur some ideas of your own.

I’ve left this example applied on my demo site. You can always go here to see all the examples from the blog.

I like the definition from About.com:

SSL stands for secure sockets layer. It is a security protocol to enable Web sites to pass sensitive information securely in an encrypted format. It is based on the RSA Data Security’s public-key cryptography.

So, what does this mean for you and your users? Not much will change really. For the most part, this process will take place without either of you noticing. However, if you have created your own login form, then will be repercussions you should be prepared for on release day.

In your login page you must define the form’s Action property. This is the URL where the form will post the login information: https://www.four51.com/ui/logon.aspx. Most likely you currently do not have https as the protocol in the URL. This is what has changed. Once the release is completed your form will fail if you are still using http://.

What actually happens? It’s very simple actually. Using SSL means that all the information sent to the server will be encrypted. The encryption is handled by your browser and our servers can decrypt that information so it can be read. After the login is complete you’ll notice that the URL no longer contains the https. That is because the information presented does not need encryption. Once your user navigates through the billing process the security will once again be invoked.

You do not need to set up SSL on the server that hosts your custom logon page, if different from Four51. The encryption takes place in the transfer of the data to the server.

This feature is part of our ongoing effort to provide the most secure environment for your purchasing customers. Other features such as Password security strength requirements, password reset for lost password rather than providing the password, and account lockout due to login failure are successors to this feature. Look for more in the near future.

Example code:


[[InputValue]]
[[DisplayValue]]


I begin with two variables, named InputValue and DisplayValue. I’m using two because we need to do a little something different with the first spec in the form. For this example I’m taking the approach of controlling style aspects through javascript functions. This can easily be done with CSS.

Now let’s look at the JavaScript. You’ll see that we are using InitializeSpecForm() again for the first time in a while. The first four lines of this method are setting default style properties and the text we want to use as a label. From here I want to skip down to examine the following: spec['DisplayValue'].onfocus = function() {
this.value = '';
this.style.color = 'black';
}

spec['DisplayValue'].onblur = function() {
if (this.value == '') {
this.value = 'Title';
this.style.color = 'gray';
}
}

I’m assigning a function to two events of the spec control: onfocus and onblur. The event, onfocus, is fired when the cursor is set in the textbox (from tabbing or clicking into it). The onblur event is the opposite. Once the cursor leaves the textbox it will be fired. In the onfocus event we want to remove the label and set the text color to black. Once the user leaves the textbox we now want to check if a change was made to the default text, and if not set the text back to the label value.

There is a difference with the InputValue spec because it received focus initially on page load. This will fire the onfocus event and remove the label, which will leave the user wondering what they are suppose to enter in that field. So, we compensate for this by keeping a count of how many times the InputValue has received focus. If the count is greater than 1 then we want to hide the text and set it to black.

As always you can go to my demo site to see this example in action by clicking here.

The price schedule table already exists in the Product Detail customization feature. When rendered it is a basic HTML table that displays all the price breaks for the current product. Because so many basic products are orderable from the product list page, we decided to include the ability to display this table here as well. Take note that the price schedule will only display for products that can be ordered from the product list page, and a price schedule must exist for that product.

In the example, I want to show you two things. First, how to edit the customization using table less layout. Secondly, how to put the new price schedule token in a mouseover. Take the example with a grain of salt as I have absolutely no design skills whatsoever. I’m merely attempting to demonstrate some techniques you may find useful.

Example code:


A couple prefacing notes: it’s probably best to put your css definitions in your theme’s stylesheet(s). In this example it will be repeated for each product in the list making the page slower to load. I’m not suggesting this is a quality layout. I wouldn’t copy and paste this example into your site customization.

So, let’s examine a few details in the example. You can see that I’ve elected not to use a traditional table layout. I’ve divided the content into sections by placing it in div tags. Without style applied div tags assume 100% width. Consecutive div tags will flow-like paragraph breaks. Creating a horizontal layout is accomplished through the css styles in the example. For instance, position: relative, implies the content will anchor in the items parent (the final parent will be the document itself). So all coordinate settings will refer to the parent’s top left most location as 0,0. This concept is certainly familiar to designers. Once I determined layout coordinates that would not cause overlaying of items, I moved on to the actual price schedule popup.

A couple important notes about the price schedule content. I applied the class popup to the div container tag, and I’m using the [[ProductID]] token as the id of the div container. This ensures that the ID is unique to the page. The two key components of the .popup css definition is the display and z-index properties. I simply want to ensure that the price schedule is the topmost item on the page so I safely assume that 999 for the z-index will be adequate. I also need to make sure the price schedule begins hidden, and this is accomplished with the none value set to the display property. Now let’s move on to the actual mouseover effect.

I’ve chosen the area that holds the thumbnail as the item which will trigger the effects. Within the div container tag I’ve placed two event definitions: onmouseout and onmouseover. I think their purpose is obvious from their names. I’m actually placing the javascript within these event declarations. document.getElementById('[[ProductID]]').style.display You now should see why the ProductID token as the ID was important before. We are referencing the price schedule to display by that unique id. The style.display properties I’m using for show and hide are: none and inline.

The price schedule token is new and has not been release yet. In order to see this example in action, you’ll need to use your regular login to my demo site in the beta environment. Then look for the Basic Product in the list. For an additional example of a new feature, look at the sort options now available.

I’m the first to point out that the default look and feel of the Four51 site is rather dated. I personally would not want to roll out a buyer site with that theme applied, but I also do not have a creative bone in my body. I cannot design a web page to save my life. Sure, I can handle the technical aspects of writing the HTML markup but you would never want me creatively designing anything. To make matters worse, I’m also color blind. Thankfully, we’ve contracted some skilled designers to create a number of stock themes for you to apply to your site.

Previously, you had to contact customer support to have a theme applied; not any more! The new theme management feature allows you to assign themes to individual buyers. You can apply them and log in as a user to check out the different styles. For those that have visited my examples site, you’ve seen one of them already.

Additionally, you are also able to create and manage your own custom themes. If you haven’t examined how to create your own them yet, we have training available (check out the training section of Access Four51 for more info). Our implementation of this feature offers you an unprecedented level of freedom in designing your buyer site. Currently there are over 600 custom themes on the Four51 application.

Next week I’ll be touching on customizing the Product List page and focusing on using the new Price Schedule token.

Name
Address Line One
Address Line Two
City, State Zip Code

If a user enters text that is too long for “Address Line One”, but does not enter text that is too long for the other variables, you likely don’t want to copy fit the other lines. Using Pageflex’s grouping, copy fit, and auto-hide features, you can allow for this very easily. In the following example, we discuss how to configure this for a block of text with four lines of text: Name, Address Line One, Address Line Two, City/State/Zip Code.

Here are the general steps we used to create the example:
———————————————————————————————————
1. Draw four separate text boxes, one for each line of text: Name, Address Line One, Address Line Two, City/State/Zip Code.

2. Set the Flex Width property for each text box to “Minimize”.

3. Create a vertical group including all four text boxes, and set the group’s Vertical Alignment and Horizontal Alignment properties appropriately. This step is necessary to ensure desired collapsing.

4. Optionally, set the Bumper properties of each text box to accomodate for desired leading between text boxes.

5. Create an “Advanced” copy fit rule. You may create the rule to copy fit any of the following attributes: Font Size, Leading, Horizontal Scale, Space Before, Space After, Tracking. Be sure to check the option for “Fit paragraphs on single lines”. This will ensure that text does not wrap.

6. Apply your copy fit rule to all four text boxes.

7. Create four Plain Text/Constant variables named the following: Name, AddressLineOne, AddressLineTwo, CityStateZip. Apply these to the corresponding text on your template.

8. With your pointer tool, select the text box containing the Name variable. Go to the Flex tab of the Properties dialog box and look for “Auto-Hide Condition”. In the “For Element” box, enter “Name” (without quotes).

9. Repeat step #8 for AddressLineOne, AddressLineTwo and CityStateZip.
———————————————————————————————————————

To see a working example of this project and to download the project files, click here.

To upload a file, we will be making an HTTP POST with the file in the Body of the message. The server will accept the POST and return a response indicating success or failure. The server receives the request, parses the querystring value and, if valid, reads the body (uploaded file) into a buffer and saves it to the variable spec. The logic is very simple, which is good because there are very few things that could potentially go wrong and therefore make it easier to debug.

After creating a variable spec (file type) and enabling remote upload the application will display the URL you need to use for posting. The GUID in the querystring contains all the information the application needs to identify what to do with the file.

Sample URL: http://www.four51.com/UI/FilePrint.hcf?id=a93bb1be-20cd-4f58-b402-a381a551e0c1

Now let’s walk through creating a very simple C# project that will perform a file upload.

This is where the two services are quite similar. The code to open a local file and upload it is identical. We’ll only need to change the HTTP POST url.


string Four51URL = String.Format("http://www.four51.com/UI/FilePrint.hcf?id=a93bb1be-20cd-4f58-b402-a381a551e0c1");

try
{
TextReader responseReader = new StreamReader(webError.Response.GetResponseStream());
message += responseReader.ReadToEnd();
responseReader.Close();
}
catch
{
message += "Failure: Can't read response.";
}
MessageBox.Show(message);
}


Without attempting to detail all of the aspects of this code, you can read about it in detail here. In summary the code is opening a web request, a local file to insert into the body of the POST and processing the POST.

The receiving web service ingests the body of the POST and uses the querystring parameter to locate the product and attach the file to the proper file spec.

Overall, this is a very simple web service to implement. Of course, this example is probably not adequate for your production environment. It is a good starting point that you can extend for more functionality. Additionally, Four51 has created component services that allow you to distribute print drivers to your customers that use this service. They then have the ability to click “Print” from any application and print the file directly to the Four51 application.

One strategy that helps when implementing these challenging projects is to use layers of variability. Layered variability means embedding variable content inside of variable content. For example, you can embed variable area templates inside variable area templates. You can embed variable text inside of variable text. You can even mix embedded variable content as long as you stay within the boundaries of Pageflex’s content rules. For example, inside a variable area template, you can embed variable text or a variable image.

Layering variables basically means creating a bunch of rules (or scripts) that control content on several different levels. According to Pageflex, there is no limit to the number of layers you can implement, giving you endless options for how to configure your projects. In the following example, we discuss how to implement a template where a user can choose from a logo selection or enter their own tagline text, but not both. Either the logo appears or the tagline appears. There are two layers of variability to this project:

Layer One: Controls whether the logo OR the tagline appears.
Layer Two: Controls the specific logo OR tagline text to appear.

Here are the general steps we used to create the example:
———————————————————————————————————
1. Draw an Area Template container on your pasteboard.

2. Place an Image container inside the Area Template.

3. Create a source variable for the logo selection:
Variable Name: LogoSelection
Kind: Plain Text
Source: Constant

4. Create an image rule for the logo:
Variable Name: LogoRule
Kind: Image
Source: Rule
Rule Definition:
If “LogoSelection” Is “Logo A” Result Is “LogoA.jpeg”
Else If “LogoSelection” Is “Logo B” Result Is “LogoB.jpeg”
Else If “LogoSelection” Is “Logo C” Result Is “LogoC.jpeg”

5. Apply “LogoRule” to the Image container inside the Area Template.

6. Select the Area Template container with your pointer tool, and then export it as a file into your Area Templates folder. Name the file “LogoVersion.xat”.

7. Delete the Image container inside the Area Template, and then draw a text container inside the Area Template container.

8. Put some default text into the Text container, and then apply a source variable. Use the following variable definition:
Variable Name: CustomerText
Kind: Plain Text
Source: Constant

9. Select the Area Template container with your pointer tool, and then export it as a file into your Area Templates folder. Name the file “TextVersion.xat”.

10. Create a rule for the Area Template container:
Variable Name: VersionRule
Kind: Area Template
Source: Rule
Rule Definition:
If “LogoSelection” Is Not Result Is “LogoVersion.xat”
Otherwise Result Is “TextVersion.xat”

11. Apply “VersionRule” to the Area Template container.
———————————————————————————————————

To see a working example of this project and to download the project files, click here.

There are several benefits to layering variables in your Pageflex projects:

1. Layered variable content make multi-version projects possible, which otherwise would require several different projects.

2. Layering variables reduces the total number of elements in a project. A common mistake amongst template designers is to create a separate static area template for each version. You can reduce the number of content files by embedding variables within your content files.

3. Using layered variable content makes modifications quicker. If you need to make a change that affects an underlying element, you only need to make the change once.

There are also drawbacks to using layering:

1. Initial setup can be complicated and difficult to grasp. Creating templates with several layers of variability requires planning. Your first few templates will take longer to setup, but after several projects, you’ll find that you save a great deal of time.

2. Troubleshooting issues can be difficult. Sifting through lots of different rules and content files to find the specific cause of an error takes some work. Projects often appear to be a tangled mess of nonsense, especially if you did not build the template.