Home > Form Elements > Button
Basic Attributes
As of Build 701, this field accepts the standard RackForms 2 token set for field labels. Please see the in-app tooltip for exact values to use.
As of Build 705, this field now accepts the standard RackForms 2 token set for Section/Headline Text and Body Copy elements. That is, we used to only be able to use the @{value} token, as can now use F{}, S{} and so on.
The 'new' RackForms standard tokens will, by default, transform line breaks into HTML br tags. This is very handy when we want to display a text area to a user where such line breaks have been added. This ensures the typed value matches, as closely as possible, the display.
Also in Build 705 is the 'raw' field token: FR{field_name}. This token was created because by default, when we use a F{} token for say, text1, we are actually creating the following code:
<?php if(isset($_SESSION['qs']["{$_SESSION['entry_key']}"]['text1'])) { echo "{$_SESSION['qs']["{$_SESSION['entry_key']}"]['text1']}"; }?>
That is, a full (but inline) PHP block. This makes it impossible to create custom logic in a Body Copy or Section Text block, as the open and close PHP blocks break any such custom code.
Thus, the raw token only places the raw field value into the text data, nothing more. The same text1 item now looks like:
$_SESSION['qs']["{$_SESSION['entry_key']}"]['text1']
That is, no PHP block, and no isset().
Conditional Processing
Conditional Processing Overview
The conditional processing capabilities of RackForms can be broken into two main categories:
Guided - In this mode we use all fields except the Custom Conditional Field Statement text area. That is to say, we use the RackForms user interface to select one element or wrapper to apply dynamic logic to. This could be considered the "easy" mode, in that we write no code to perform our dynamic logic. We simply tell RackForms the properties of the interaction we want and RackForms does the rest.
Custom Conditional Code - In this mode we use the Event Trigger property say which event calls the code we define in the Custom Conditional Field Statement box. This could be considered the more powerful but advanced mode, in that we write our own dynamic logic.
Of course with power comes flexibility, as in this mode we can apply any type of complex logic we need to get the job done. In particular though this code-centric mode is required if and when we want to apply dynamic logic to more than one field item or wrapper class item (items that have the same Wrapper Class property defined).
To be clear: if we only need to apply dynamic logic to one item or wrapper class we use the guided mode. If we need to have more than one item show or hide, we use the custom code mode.
Important Note
Starting with Build 759 we can use the Guided mode controls to apply conditional logic to items on a different page than the one the affecting form field is on.
Please note however, that this capability does not apply to Custom Conditional Code logic, only guided ones. That is, any custom conditional code we write only applies to items on the same page.
Determines if the form element is visible when the page first loads. Please note that this logic always resets on page load, that is, if a user goes back one page where an element was previously shown it will be invisible again .
This field and the next allows us to create a condition on the visibility of the field. We enter the Name/Value of a form field in this box, and in the next, the value we check against. If the value matches, we show the field. Please note this only works as a method to show a field, not hide. That is, we still uncheck the Field initially Visible to hide the field, these options simply allow us to show the field based on a condition from another form field. Please note this logic works across pages.
The value we check to determine a fields visibility. This must exactly match the value the form field will contain. This field is also dynamic, which means we can use standard RackForms tokens to check against a dynamic value at run-time.
In general we want to keep this box checked, though if you wanted to force a field to always show after an action then leave it unchecked.
Caution! You may run into a situation where you build a form that enables the event trigger on a specific field, then remove that field later on without updating the Event Trigger's 'binding' to that element.
If this happens your forms validation will break, along with other potential issues.
The solution is always make sure that when we enable an event trigger for an element, that field exists on the form.
It is also important to note that RackForms will attempt to cast comparison values set as INT and FLOAT values to their respective native types.
As you build your form RackForms will automatically track the Name/Value properties of the elements on that form page and then present them to you in list format in this field. Thus, all eligible form fields will be displayed in this select item, the one you select will become the field acted upon.
Finally, any elements that are set to hidden on page load are tagged with a [H], which makes it easy in many cases to see which items you may need to work with.
Note that items from other pages will be shown as well, they are grouped with an entry of the page name they below too.
The bulk of this logic will be derived from a JavaScript object called fbc. This object is defined in:
/rackforms-root/app/movefiles/conditional.js
This file is exported into the root of all RackForms jobs.
The basic usage of this object will depend on what action you want to perform. Their are 4 methods you need to know about:
hideField, hideWrapper, showField, showWrapper
As shown in the editor, we call these methods as:
fbc.showField(event, 'FieldName', 'animation');
With a simple example to show a text box being:
if(in_value == '1'){
fbc.showField(event, 'text2'); // animation argument is optional, event and field name is not!
}
Simple enough--But it is important to understand that at the page code level RackForms creates two distinct but related items.
The first is the event trigger which is placed inline with your form element. Please be aware the event used is not created automatically, you need to select one from the Event Trigger select item.
Thus, if we select the onKeyUp event RackForms will place this code inline with your element:
onkeyup="fb_dyn_text1(event, this.value, this)"
Notice we have three arguments. This is important because the inline method call is directly tied to the second main element RackForms creates for you, which is a script tag with that methods definition.
This method looks like:
function fb_dyn_text1(event, in_value, elt){
if(value == '1'){
fbc.showField(event, 'text2');
}
}
As you may now see, this method body is the code you create in the Custom Conditional Field Statement text area. The reason why it is wrapped in the method is to that you do not need to worry about creating or gathering the event, in_value, and elt parameters.
Thus, the last bit of knowledge to convey is that these parameters, event, in_value, and elt, can be used in any way you need in your Custom Conditional Code. Most of the time you will only need the in_value parameter for your logic, but please notice you must pass event to the fbc functions no matter what.
Place hide field calls at the top of the code section.
One common trick to employ to keep your code block clean is to place all hide calls at the top of your code block. This eliminates the need for most if/else blocks, and means we only need to set conditions to show elements. The reason this works is hiding and showing elements is so fast, that even if an item is shown and will not be hidden by the code, the hide call and subsequent show happens to fast to be perceived.
Be careful with integer values.
Integer and number values in JavaScript can often cause problems, as they may be interpreted as strings, and vice versa. Thus, when working with number values always pass them through isNaN (is not a number), and parseInt/float. For example, the following code will check to make sure k is a number, and is also an int.
var k = 10; if(!isNaN(k)){ // is this a number? if(parseFloat(k) <= 10) { // parse and check value console.log(1); } else { console.log(0); } }
Watch which Event Trigger we use.
Generally speaking, a text box should use blur, a drop down onchange, and radio and checkbox items onclick. Using different events is possible, but can lead to unexpected results.
animationDone(elt)
We use this callback inline with our Conditional Code block as in:
fbc.animationDone = function(elt){
alert(elt.id);
// when animation is done, call resize function for iframe
window.parent.resizeSubForm(getOutputSize());
}
That is, we call fbc.animationDone(elt), then in that function, define the actions to take place.
The elt parameter is the object that called the animation, that is, is the object which reacted to the event.
Please note this event is fired for every animation that plays. Thus, if we've used this in the content of a Wrapper Class with say, 5 elements, this function is called 5 times.
Important RackForms Note: In RackForms 2 the in_value parameter was defined as just value. This caused code conflicts however, and was thus renamed to the present value. If importing any RackForms 2 jobs into RackForms, any custom code will need to be updated to use the new value.
In 2007 we had a simple idea: make building web forms fun and easy, and most importantly available to as many users as possible. Years later we're still going strong and though the software has grown by leaps and bounds, still find building forms as easy as we had hoped.