Skip to content

F2 Version 2

Jump to bottom
Mark Healey edited this page Jan 23, 2014 · 6 revisions

Note: This is a draft document as we collect ideas into a single location. Once this transfer of knowledge is complete, we will remove this message and begin further discussion either via a separate Issue or Pull Request.

This page has been setup to track some initial thoughts and ideas for F2 version 2. Currently, the major goals of version 2 are:

  • Make F2.js more AMD compliant
  • Enhance the F2 standard to be simpler yet more powerful while updating it to include features not currently available

We hope to list some of the pros/cons within this wiki page. As we get closer we will start a branch and associated Pull Request to track the changes required for v2.

Table of Contents

Structures

AppManifest

We propose to keep the AppManifest largely the same but some additional properties will be added to help with defining modules and dependencies for those modules. Most notably, the AppManifest now uses a dynamic JSONP callback by default which is discussed further below.

F2_824076({
  scripts: [],
  styles: [],
  inlineScripts: [],
  apps: [
    { 'data': {}, 'html': '', 'status': 'good' }
  ]
});

Questions/Issues:

  • Should an AppManifest have a paths or even a shim property that could hook into the container's paths or shim in the require.config?
  • Ideally the only script that would be returned in the AppManifest is for the AppClass since the dependencies should be defined in the AppClass. Should we make this a requirement?

AppClass

We propose to update the AppClass to follow the AMD pattern for defining a module. This means that apps will no longer need to be placed into the F2.Apps object.

define('com_example_helloworld', ['F2', 'jquery'], function(F2, $) {
  var AppClass = function(appConfig, context, root) {
    // Implementation
  };

  // Extend the built in AppClass provided by F2
  AppClass.prototype = new F2.BaseAppClass;

  return AppClass;
});

Questions/Issues:

  • This pushes container developers in the direction of AMD. What happens to the sites that do not wish to follow the AMD pattern?

    F2 should provide a separate download that bundles Almond and LazyLoad (or even just RequireJS) which will provide the necessary define and require methods.

  • Specifying a module name is sometimes frowned upon in the AMD community, how can apps be written so that they do not use a hard-coded module name?

    If the AppClass file is named with the AppID, this should get around the need to hard-code the module name. For example, www.example.com/apps/com__example__helloworld.js is named in such a way that it could use a define statement without needing to specify the module name.

AppConfig

API

AppManifest Requests

F2 v1 used a hardcoded JSONP callback such as F2_jsonpCallback_com_example_helloworld() by default which causes issues such as #113. It is proposed that F2 v2 use a dynamic JSONP callback by default, with an option to use a static callback for apps that cannot handle a dynamic callback (also called out in #113). The proposed dynamic callback could be generated by something such as 'F2_' + Math.floor(Math.random() * 1000000).

In addition, it is proposed that the internal stylesheet loader be updated so allow for callbacks in browsers that support it. This would resolve #83.

Questions/Issues:

  • How does an app define whether or not it can handle a dynamic callback?
  • See #73
  • Should F2 resolve relative URLs in AppManifest, AppClass?

Namespaces

It is proposed that we flatten the API and put more methods on the root F2 object. An example of this is to make F2.Events.emit() into F2.emit().

Questions/Issues:

  • In v1, there are methods like F2.UI.Views.on. If the namespaces were flattened, the UI.Views method would conflict with the Events method. How should these be handled?

Plugins

The issue of plugins and extending F2 was originally brought up in #121. How to develop and use plugins should be fully fleshed out in v2.

// need code examples

Schemas

It is proposed that F2 add JSON validation in order to validate the various types of objects that are passed around such as AppConfig, AppContent, AppManifest, and ContainerConfig. The validation methods could also be utilized for "Data Apps" and validating that the data being passed adheres to a predefined spec.

// need code examples

Questions/Issues:

UI

F2.UI will see an overhaul in version 2. In version 1, F2.UI was tightly coupled with Bootstrap (specifically modals). In version 2, we propose providing an F2.UI interface in which container developers must implement to provide UI functionality. This will enable container developers to use the UI library of their choice (Bootstrap, jQuery UI, custom, etc.).

/*
  Inside the Container

  The container will provide the implementation for the single 
  "F2.ui.modal" function. Apps that want to create a modal will 
  call this method and pass a configuration, object.
*/ 
F2.config({
  ui: {
    modal: function(options) {
      // Get markup for each of the buttons
      var $buttons = options.buttons.map(function(config, i) {
        return $('<button />').text(config.label).on('click', config.handler);
      });

      // Make the modal DOM structure
      var $html = $('<div class="modal fade" />').append(
        $('<div class="modal-dialog" />').append(
          $('<div class="modal-content" />').append(
          $('<div class="modal-header" />').append(
            $('<h4 class="modal-title" />').addHtml(options.title)
          ),
          $('<div class="modal-body" />').append(options.content),
            $('<div class="modal-footer" />').append($buttons)
          )
        )
      );

      // Launch the modal using bootstrap's "modal" jQuery plugin
      $html.modal();
    }
  }
});

/*
  Inside an F2 App

  Apps will be able to call the "F2.ui.modal" function. Through
  a config object, they will be able to specify title, buttons,
  and the body of the modal.
*/ 
F2.ui.modal({
  buttons: [{
    label: 'Dismiss',
    handler: function(e, closeFn, modalNode) {
      // Close the modal using the provided function
      closeFn();
    }
  }],
  content: '<p>You are looking at an example modal.</p>',
  instanceId: this.instanceId,
  title: 'Example modal'
});

Questions/Issues:

Spec

App Validation

It would greatly simplify App Development if there was an App validation service that validated an app and its dependencies for adherence to the F2 spec. The checker would ensure app CSS was properly namespaced, an AppId was properly formatted, AppClass was properly scoped, etc.

Questions/Issues:

  • Which service provider will build and host the web services?
  • What is the entire list items to validate in scope?

Data Apps

We propose adding support and documentation for Data Apps. Data Apps are really web services coupled with F2 events and could theoretically perform more actions than GET. The effort of standardizng web services, and particularly their I/O, isn't something to be taken lightly. Many suggestions have been made to look at various data type schema standards and validation will be important.

Questions/Issues:

  • Should F2 use FIX or part of it? If not, what about OpenData or similar?
    • There are informal "FIXON" (that is FIX + JSON) efforts out there, like this
  • Object validation is critical, see above

Identity Services

We propose adding Identity Services support and documentation. Identity Services are web services provided at a common endpoint where Container & App Developers could query databases to get identifiers for entities including tradeable instruments (equities for example), people, countries, etc.

Questions/Issues:

  • Where is this data?
  • Which service provider will build and host the web services?
  • What is the entire list of "entities" in scope?

Changes

  • Responsive Web Design: Upgrade to full Bootstrap 3 support or replace Bootstrap.
  • Examples: Update all example containers & apps, add Node.js versions
  • F2 AppId: Require it?
  • Third Party Lib use: F2 does not intend to compete with other 3rd party MV* libs such as Angular, React, Ember, jQuery, etc. Add mention of this, point to examples, demonstrate compatibility and interop.
  • Context: Private messaging
  • Secure Apps:
  • F2 UI:
  • Entitlements:
  • Authentication:
Clone this wiki locally