The preLoad function is the apps first interaction with the server. Most of your data should be loaded here. However, it is important to note that the app's primaryData is not available here.

If your preLoad function returns a promise, the app will halt execution until the remote data is resolved from the server so that the data will render.

Facade.Behaviors.App.preLoad( function(){
    //OPTIONAL - return resolving data to force the application
    //to wait until data is resolved before it renders
    return Facade.Resolver.query(...);
});

The onLoad function is your applications first access to your app's primaryData.

If your onLoad function returns a promise, the app will halt execution until the remote data is resolved from the server so that the data will render.

Facade.Behaviors.App.onLoad( function(){
    //OPTIONAL - return resolving data to force the application
    //to wait until data is resolved before it renders
    return Facade.Resolver.query(...);
});

The preDestroy function allows the ability to cancel the destruction of the application.

If your preDestroy function returns a promise, the app will halt execution until the remote data is resolved from the server.

Facade.Behaviors.App.preDestroy( function(){
    //OPTIONAL - return resolving data to force the application
    //to wait until data is resolved before it renders
});

The onDestroy function is the hook to complete final cleanup for your application.

If your onDestroy function returns a promise, the app will halt execution until the remote data is resolved from the server.

Facade.Behaviors.App.onDestroy( function(){
    //OPTIONAL - return resolving data to force the application
    //to wait until data is resolved before it renders
});

The setPages function allows a FEF developer to dynamically create the pages in an application. By default, a FEF application reads its pages directly from its pages.json file. However, if a FEF developer has a FEF application that has a variable number of pages; use this method.

The setPages method returns an array of Pages that must be registered in the PageRegistry. Get a Page from the PageRegistry by using the Facade.PageRegistry.get('page'); syntax.

Setting an app's pages can be useful when using the Wizard archetype if you have an unknown number of wizard pages.

//Set your apps pages
Facade.Behaviors.App.setPages( function(behaviorFn) {
    var pages = [];
    pages.push( Facade.PageRegistry.get('Fef Testing') );
    pages.push( Facade.PageRegistry.get('End') );
    return pages;
});

By default, a FEF application starts on the page indicated by the start : true field added to a page within your pages.json file. However, if need be, you can set your starting page programmatically.

Here, return a page from your PageRegistry to start your application on:

//Set your apps starting page
Facade.Behaviors.App.setStartingPage( function() {
    var myStartingPage = Facade.PageRegistry.get('myPage');
    return myStartingPage;
});

Access the app's actionSet to override your DataCoordinator's setActions method of your actionSet. In this method, access the apps actionSet by calling behavior.resume().

Return an array of actions from this method. The array of actions will be your app's actionSet.

Here, return a page from your PageRegistry to start your application on:

Facade.Behaviors.DataCoordinator.actionStrategy().actionSet().setActions(
function(behaviorFn){
        var actions = behaviorFn.resume();
        if(actions){
            var data = Facade.PageRegistry.getPrimaryData();
            //Alter your actionSet
        }
        return actions;
    });

If you only need to append an action to your actionSet, you can use the appendActions method of the actionSet():

//append action clientValidationAction
Facade.Behaviors.DataCoordinator.actionStrategy().actionSet().appendActions( 
    function(){
        return 'clientValidationAction';
    });

Access an action of the actionSet by its name; using the action('str') method. If your action is a workflow action, access it using wf_action

var someAction = Facade.Behaviors.DataCoordinator.actionStrategy().actionSet().action('myAction');

You can also change the actionType of your action and change what happens when the action is triggered through your FEF UI. Your action is triggered onClick of its button in the action group by default.

//Set Action as a transition type of action
someAction.setActionType( Facade.Constants.ActionType.TRANSITION );
//Set functionality to occur onClick of your action
someAction.setExecute( function(behaviorFn,args){
    //Occurs when action is triggered
});

To run code after your transition function executes, do something like the following

someAction.setExecute(function(behaviorFn,args){
    return behaviorFn.resume().then(function(){
        //perform functionality post-transition here
    });
});

If you want to manipulate the actionSet for a specific page, use the following forPage technique. This will allow the FEF developer to only modify an actionSet for a specific page rather than across your entire application.

//Get the actionSet for page startingPage
Facade.Behaviors.DataCoordinator.actionStrategy().forPage('startingPage').actionSet()

Your app's actionSet() draws its actions from the actionSet() of each of your apps coordinated roots. In order to explicitly set your coordinated roots, utilize the setCoordinatedRoots function of your Action Strategy. Here, we return an array of data to serve as the roots to our app's actionSet. The data must be registered in the Data Registry. Your app's actionSet can draw from any instance data in your application.

In the code example, let's say we want our app's actionSet to be actions from our primaryData and from a primary object that we loaded into our application and stored in the DataRegistry using the key otherPrimaryRoot. Here, we will add that otherPrimaryRoot to our actionSet. Thus, our docbar will have buttons for all of our actions in our actionSet.

Facade.Behaviors.DataCoordinator.actionStrategy().setCoordinatedRoots(
    function(behaviorFn, args) {
	    var roots = [];
	    roots.push(Facade.PageRegistry.getPrimaryData());
	    roots.push(Facade.DataRegistry.get('otherPrimaryRoot');
	    return roots;
    });

Set an action as tasked by returning the action in the setTaskedAction method. A tasked action displays as an emphasized button on the docbar.

Facade.Behaviors.DataCoordinator.actionStrategy().setTaskedAction(function(){
    return '<your action you want tasked>';
});

Your applications current actionSet can be accessed during the runtime of your application by dealing directly with the DataCoordinator. For example, let's say that we want to set a components mask depending on our current actionSet.

var component = Facade.Components.Button.forName(...);
component.setMask(function(behaviorFn,args){
    //get actionSet runtime of your app
    var actionsetRuntime = Facade.DataCoordinator.getActionStrategy().getActionSet();
    //or
    //access a single root's actionset
    var root = Facade.DataRegistry.get('...');
    var actionsetRuntime = root.getDataStrategy().getActionSet();
});

Note that we are not going through the Behaviors endpoint - we directly deal with Facade.DataCoordinator

Once you access the actionSet runtime, the following functions could be useful

• Get Actions — returns an array of all your current actions in your actionSet

  var myActions = actionsetRuntime.getActions();

• Get Action — get a specific action of your actionSet

//Get a workflow action named start
var myAction = actionsetRuntime.getAction("wf_start");
//get actiontype
myAction.getActionType();
//execute the action - will return a promise while the action executes
myAction.execute();

• Get PDF Actions — get list of pdf actions associated with an actionSet

  var pdfActions = actionsetRuntime.$getPdfActions();
  //Execute first pdf action at runtime
  actionsetRuntime.getAction( pdfActions[0] ).execute();

Overrides default coordinated roots that produce activities to your FEF UI

Facade.Behaviors.DataCoordinator.activityStrategy().setCoordinatedRoots(function(){
    var roots = [];
    //add roots
    roots.push( Facade.DataRegistry.get('someData') );
    return roots;
});

Along with the default activities that FEF shows on the UI, a FEF developer can throw a custom activity to the UI. A possible purpose of such an activity could be requesting information from the server during user interaction with your application. Perhaps we want to alert the user that we are requesting information and then give a message once the data is resolved.

Firstly, we want to add a custom action to our activityStrategy. Use the appendActivityCodesReportedToUser() method to explicitly indicate to FEF that the activity we are able to generate should be reported to the UI

Facade.Behaviors.DataCoordinator.activityStrategy()
                            .appendActivityCodesReportedToUser(['someAction']);

Now, any activity that we generate that has activityCode : someAction will be shown to the user

Let's say that we want to throw a custom activity when a user clicks a button. An activity is made up of steps. Each step in the activity must be another activity or a promise. In this case, we will add one step to our activity and pass it a promise. Once the activity is added to our ActivityLog it will complete the promise. The following are common parts of an activity:

• activityCode — indicates the activty code of the promise. If you are creating a custom activity, this should be the same as the code you added to your activityStrategy to be reported to the user
• text — the text that displays while the steps of the activity are resolving
• relatedTo — data that is related to the promise
• resultText — text that displays when activity finishes
• status — status of the activity - usually either SUCCESS or FAILURE

Here is an example of an activity that searches for users and shows the user

//On click of the button, trigger the activity
Facade.Components.Button.forName('myBtn').setOnClick(function(){
    var data = Facade.PageRegistry.getPrimaryData();
    //Set the activites code, status, text,and relatedTo data
    var activity = Facade.ActivityLog.add(new Facade.Prototypes.Activity(undefined,{activityCode: 'someAction', relatedTo: data, text: "Resolving"}))

    var promise = Facade.Resolver.query('User');
    //Add a step to the activity - on callback of the promise, set the activities
    //status to success and set its result text
    activity.addStep( promise.then(function(res){
        activity.setResultText("Its all done");
        activity.setStatus(Facade.Constants.ActivityStatus.SUCCESS);
    }));
});

When your activity completes, you will get the following message on the screen:

Here is an example of how to throw an error message to the UI. In this example, we are essentially setting up a client-side data validation. We want to throw an error if a field, named name, is not populated. We will perform this validation check when the user clicks the save button.

Notice below that we are intercepting the save strategy's setExecute() function. If the name field is filled out, we simply call behaviorFn.resume() to resume the default save strategy.

// Perform validation on click of save button
Facade.Behaviors.DataCoordinator.saveStrategy().setExecute(function(behaviorFn, args) {
    var errorMsg = "Trading Partner Name is a required";
    var rootData = Facade.PageRegistry.getPrimaryData();
    if (! rootData.get('name') ) {
        var activity = Facade.ActivityLog.add(new Facade.Prototypes.Activity(undefined, {
            activityCode: Facade.Constants.ActivityCode.SAVE,
            relatedTo: rootData,
            text: "Save"
        }))
        //Add a message, giving it the code of type ERROR so the UI
        //will display the error in red
        activity.addMessage(new Facade.Prototypes.Message(undefined, {
            messageType: Facade.Constants.MessageType.ERROR,
            text: errorMsg,
            relatedTo: rootData
        }))
        //Throw the activity to the UI
        Facade.FunctionRegistry.execute("core.activityLog.onUIActivityComplete", {
            activity: activity
        })
    } else {
        //If the name is properly set, resume the behavior. In this case, the default
        //behavior is to execute the saveStrategy of your application
        return behaviorFn.resume();
    }
});

Let's say we have multiple roots in our application and we need to persist any changes in either root to the server. To do this, add candidates by their instance type to your saveStrategy using the following method. This overrides the default candidate structure - so add all of the types that need to be persisted within your application.

Facade.Behaviors.DataCoordinator.saveStrategy().candidates().
                            forType('$FefTestQuestionQ1', '$FefTestDesign1S1');

The above code indicates to the saveStrategy to look for any data in your data registry that is of type $FefTestQuestionQ1 or $FefTestDesign1S1. Now, if any data that is of that type is modified and is thus dirty, your save button in the docbar will be enabled and onClick will persist changes to the correct object instances automatically.

Let's say we have multiple roots of our app but we only want to persist changes to certain pieces of data to the server. We can do this by explicitly setting the candidates of our saveStrategy using the setCandidates method. When overriding this method, return an array of data prototype objects that are registered in your Data Registry that you want to persist to the server. Once this method is overridden, your saveStrategy will only check these candidates for dirty-ness

Facade.Behaviors.DataCoordinator.saveStrategy().setCandidates(
    function(behaviorFn,args){
        var candidates = [];
        //add primaryData to your candidates list
        candidates.push( Facade.PageRegistry.getPrimaryData() );
        return candidates;
    });

Similarly, add candidates to your list of candidates by utilizing the appendCandidates.

Facade.Behaviors.DataCoordinator.saveStrategy().
                               .appendCandidates([...]);

As mentioned above, the save button becomes enabled when it determines that the data that needs to be persisted is dirty. It does that with the setIsDirty() method of the saveStrategy. This method returns true or false depending on the dirty state of the data. This can be overridden by the FEF developer.

Facade.Behaviors.DataCoordinator.saveStrategy().setIsDirty(
    function(behaviorFn,args){
        //return boolean: true or false
    });

As mentioned above, the save button in the docbar fires the setExecute() method of your saveStrategy. In rare cases, there could be a use-case where this method would need to be overridden.

Facade.Behaviors.DataCoordinator.saveStrategy().setExecute(
    function(behaviorFn,args){
        //Persist the data
    });