Development Center
Manifests
An f2 manifest is an endpoint where F2 apps can be retrieved. It consists of a URL,
a friendly name, and a collection of apps. For more information on manifests, visit the
OpenF2 documentation on app development
.
Loading Apps
Loading an app is simple, just click on the app you want to load in the left rail. Fill in the dialogue
box that displays, and click loadapp. If a SampleContext or a DefaultContext was provided to the manifest,
it should auto-populate the app context with those, sample taking priority. It will default to an empty json
object otherwise. Modify the context to change the inputs to the app. As changes are made it will validate
the json, alerting you if there is a problem. Apps can be edited once loaded into the sandbox.
The state of the sandbox is saved after every change. The sandbox state will be restored upon reload
of the development center.
Events
F2 apps and containers talk to each other through custom events. The events are emitted and listened for
the apps and containers. The development center provides a simple interface for testing the use
of events across apps. This is done by hijacking the F2.Events methods.
Listeners
As an app or container adds and event listener it is added to the list of event listeners in the
Events tab of the development center. A list of event listeners allows for a quick accounting of
all events being watched by all apps loaded into the sandbox.
History
Every emit is also tracked by the development center. The event is listed in the events tab under
history. Clicking a past event will populate the "emit" section to allow for inspection of the
arguments provided or for refiring the event.
Emit
Because all interactions between apps is done through F2.Events, it is useful to be able to emit those
events manually to test those interactions. The emit section will allow you to fire a custom event
with an array of inputs or refire a past event when selected from the history.
Configurations
A necessary feature of the development center is a persistent state of the sandbox and the ability
reload or share app configurations. Every change to an app in the sandbox will result in a state
save into the browser's localStorage. This sate will be the new default on reload of the page. This
allows for quickly reloading the page to see changes in apps without losing the configuration.
Saving Configurations
Multiple configurations can be saved to localStorage by clicking the save button ()
below the tabs. This will prompt for a name and save the configuration with that name in localStorage.
Once a configuration is saved a dropdown will appear below the button group. To delete a saved configuration,
select it from the dropdown and click the delete link that gets created.
The use of localStorage means the persistent state and saved configurations will not be shared between
browsers or environments. They will also be lost if browser data is deleted.
Sharing Configurations
A configuration can be saved to disk by clicking the download button ().
This will generate a .json file that contains the json serialized version of the configuration. This
configuration can be shared with other members of your team to quickly load in a collection of apps.
Simply email your colleague the file or send them the file contents.
Loading in a configuration file is as simple as dragging and dropping
the file into the development center.
Clear Sandbox
All apps can be removed from the sandbox by clicking the clear button () in the button group.
This will clear out the current state of the apps.
Sandbox
A key idea behind the development center is to provide a pure location to load in apps and test their
display and functionality. For that reason the sandbox is loaded into an iframe with a bare minimum of
necessary javascript and CSS loaded. The only CSS rules used are highly specific to the app roots and
the only javascript is F2 and jquery (on which .noConflict() has been called).
In addition to providing a blank slate, the sandbox allows for common javascript and css files to be
added. On load of the development center, a collection of script and javascript files, defined by your
manifest, will be posted to the iframe and subsequently loaded onto the page. There should be little
to no affect on the apps themselves from the sandbox.
App Root
Each app loaded into the sandbox is placed inside of a panel. The panel has a few UI elements to make
managing the apps simpler.
Refresh
Click the refresh button () to reload the specific app. This will remove the
app and readd it in the same location. This is an effective way to test code changes on the app's backend.
A full page reload is recommended for CSS and Javascript changes as they are a little trickier due to how
F2 loads front end resourcesin those resources.
Edit
An existing app can be edited by clicking the edit button (). This allows you to modify the app context or
the dimensions of the app's root. Modifying the context prevents having to remove and readd the app.
Modifying the dimensions of the app root allows for testing the app's dynamism. For testing responsiveness,
changing the size page itself with a collapsed left rail works.
Remove
Remove an app from the sandbox by clicking the close button ()
on the app root. This effectively calls F2.removeApp().