Enhancement: F2 view

[ilinkuo]

Enhancement 1: f2-view-param to handle view transitions

F2 views are currently handled via simple replacement. There is a need for more complicated transitions. This would ideally be handled in a declarative fashion similar to the current data-f2-view and data-f2-app-view-trigger. This proposal is for a backwards-compatible API change to accommodate this concern.

• Add an optional data-view-param attribute
• The value of the of the param is a JSON object of the form {'transition': 'flip'}
• _initAppEvents JSON.parse() the param and invokes appConfig.ui.Views.change(view, param);
• The change() dispatch code uses the value of transition to dispatch to a custom handler. The handlers could be preregistered by the container via something like F2.Views.register( viewName, handler)

Example values of transition are 'flip', 'dropdown', 'slide', etc. -- basically, anything that you might find in a powerpoint effect.

[ilinkuo]

Enhancement 2: Custom view business logic handlers.

The views, even with enhancement 1, are not quite powerful enough. Enhancement 1 deals only with generic transition effects. However, there are cases where instance-specific logic must be performed which cannot be handled by the E1 mechanism without mixing business and presentation concerns. As an example, consider the following issue we ran into with Streaming News and RSS Reader

The user

• opens settings via the gear dropdown
• changes a few settings
• decides to cancel. The cancel link is implemented via only a data-f2-view parsed by _initAppEvents()
• The view change event fires, the gear is hidden. However, the "state" of the settings selections is preserved in the DOM.
• opens the settings again. This brings back the hidden view which still shows the cancelled settings.

So the programmer cannot rely on a declarative view change event added by _initAppEvents() --- he must either call the Views.change(businessMethod) method directly in his code and pass a businessMethod() , or write a custom handler, bypassing the _initAppEvents().

We propose adding declarative instance-specific view change handling to F2

• Add a appConfig.ui.Views.register( handlerName, handerFunction) method. Note that this differs from the register method in E1 because this method is on the instance's Views rather than the F2 global Views. This method would be called by the App, not the Container, in contrast to E1 above
• Add an optional f2-view-handler attribute to the element to specify the business logic
• _initAppEvents() will invoke the business handling after invoking the presentation change.

    if (view == F2.Constants.Views.REMOVE) {
        F2.removeApp(appConfig.instanceId);
    } else {
        appConfig.ui.Views.change(view, param);
        appConfig.ui.Views.handle(view, param, handlerName);
    }

[ilinkuo]

E3: _initAppEvents() needs to search from .closest('f2-app') rather than jQuery(appConfig.root) itself due to diagram in #86

In streaming news and RSS Reader, we use this snippet of code

this.$root = $(root).closest('.f2-app').length > 0 ? $(root).closest('.f2-app') : $(root);

to widen the search space. This is because unlike conventional F2 view handling, not everything is happening within the conventional appConfig.root of 'f2-app-container'. We actually pull the DOM node for the data-f2-view="settings" out into a gear dropdown which is inside of f2-app' but outside of 'f2-app-container'. When this happens, initAppEvents() is unable to find and attach events.

This has two possible implementations:

1. Add the above snippet for this.root into F2 core somewhere, creating a new appconfig.appRoot to be used to designate the "upper" root. This is backwards compatible
2. Limit the scope of this change to just _initAppEvents() itself. Change

jQuery(appConfig.root).on('click', '.' + F2.Constants.Css.APP_VIEW_TRIGGER + ...

to

var appRoot = $(appConfig.root).closest('.f2-app').length > 0 ? $(papConfig.root).closest('.f2-app') : $(appConfig.root);
jQuery(appRoot).on('click', '.' + F2.Constants.Css.APP_VIEW_TRIGGER + ...

[montlebalm]

Regarding E1, I'm not sure about allowing apps to decide which transitions they perform. If the goal is app consistency, then the container should be able to determine how views are transitioned. It would be interesting to allow the container to implement a handler method that accepts the current and new view DOM nodes so it can animate as necessary. Perhaps we could implement some sensible defaults as well.

[ilinkuo]

If the goal is app consistency

The goal is extension to add transition effects.

the container should be able to determine how views are transitioned

I think the Container should decide what transitions are available and which it implements. The App should decide which transitions it wants to use. If the Container does not implement that transition, then it can ignore it and use the default view change.

There isn't any need to have the current and new view DOM nodes as parameter. The Container already has that information.

[montlebalm]

Is there a realistic situation in which the apps should decide how they're transition instead of the container? It would be as if programs on your operating system were allowed to change their "minimize" animation. It adds configurability to the app at the cost of overall consistency.

A major goal of v2 is to drop the dependency on jQuery. It's far too easy to see how supporting a stable of animation effects would inextricably tie us to some 3rd party library.

[ilinkuo]

Is there a realistic situation in which the apps should decide how they're transition instead of the container?

The App tells the Container what transition it would like. It's up to the Container whether that is honored. It's a shared decision, but the Container has the ultimate veto.

It adds configurability to the app at the cost of overall consistency.

Again, the goal is extension, not UI consistency. UI consistency shouldn't be a goal anyway if you plan to target multiple platforms.

Keep in mind that this is just transitions eye candy, not a big deal. If the Container doesn't support the transition, then it will do a default view change, which is just wholesale replacement of the DOM node.

A major goal of v2 is to drop the dependency on jQuery. It's far too easy to see how supporting a stable of animation effects would inextricably tie us to some 3rd party library.

I completely agree with that goal, but I don't see how this proposal affects that in any way. This proposal is a specification for how transition effect requests can be communicated from the App to the Container. The implementation is a separate issue. Our effects are implemented using Dojo, not jQuery, but you could implement this using D3 if you want.

For a given specification, the actual implementation could be a choice of plugins -- Dojo, jQuery, D3, YUI, etc. There's no particular need for OpenF2 to actually support any one of those (though it's probably important to MoD's clients that jQuery is supported). To me, the dropping of the jQuery dependency is not an end goal in itself, but rather so that F2 can appeal to other frameworks.

[brianbaker]

Views were a rarely used feature of v1 that will be dropped in v2.