Query on use of Fluid Pager

[Antranig Basman]

Hi there James - sorry noone was about this afternoon in the #fluid-tech IRC channel to deal with your query 
re the Fluid Pager component which has been logged here: https://botbot.me/freenode/fluid-tech/
Firstly I'd like to apologise for this API change which is a needless annoyance. Thanks for supplying so 
many details of your problems which are very helpful in coming up with workarounds and solutions.

In terms of the Fluid Pager specifically, unfortunately we have been less careful in preserving details of 
its API than with some of our other components since this component never achieved "Production" status. It 
is listed as in "Preview" status on our API pages but I believe this is a mistake since "Sneak Peek" would 
have been more appropriate given the resources we've been able to devote to it.

Firstly in terms of a very quick workaround I can suggest adjusting the construction site at 
https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/webapp/media/skins/common/javascript/uportal/up-layout-gallery.js#L260 
to read

that.state.pager.events.onModelChange.addListener(function (newModel, oldModel) {
     that.dragManager.initDragAndDrop(newModel, oldModel, that.state.pager);
     });

This is the most "quick and dirty" scheme for adjusting for the change in this listener signature.

In terms of a Fluid best practice, we recommend that all new code is written using the declarative syntax 
described in our IoC documentation. In particular, newer versions of the framework supply a facility called 
"event boiling" of which you can see an example here - 
http://wiki.fluidproject.org/display/docs/Use+events+declaratively - it should properly be described on this 
page http://wiki.fluidproject.org/display/docs/Event+injection+and+boiling but sadly it has not yet been 
updated. I'll do this tonight.

Using this scheme you would replace the need to write manual event handling code and would instead supply 
extra configuration as part of "pagerOptions" on line 228 - for example, at line 231 you would write the 
following:

     listeners: {
         onModelChange: {
             func: that.dragManager.initDragAndDrop,
             args: ["{arguments}.0", "{arguments}.1", "{that}"]
             }
         }

Note that this is still not quite a full "best practice" because of the manual reference to a function 
handle as referred to in "func". If fully modernised, all of the code in the giant closure starting at line 
106 up.AjaxLayoutPortletListView would be moved into configuration listed in the fluid.defaults blocks at 
lines 101 and 267, which would then enable an IoC reference to the dragManager under 
"{dragManager}.initDragAndDrop" under the "func" entry above.

Moving over to this declarative style can be left for a while, but in the immediate term you'll need some 
other changes to successfully upgrade this code - at the least, you will need to change the type name on 
line 259 from "fluid.pager" to "fluid.pagedTable" since this component has been refactored into separate 
pager and table components for a better separation of responsibilities.

Although we're committed to maintaining the component APIs themselves compatible in their current form, 
there are changes to the Infusion framework itself that will break the up-layout-gallery.js usage when 
Infusion 2.0 arrives (not expected in less than a year from now). In particular low-level component APIs 
such as fluid.initView on line 110 and fluid initSubcomponent on line 113 will be withdrawn in favour of 
moving all of this material into the fluid.defaults on line 101. By this time we will have very much better 
documentation to support people in this migration, and we hope you will stay in touch in any case since we 
are always happy to help you over the bumps.

As an example of this new style (which can be used now) the drag manager and the listener binding on lines 
113 117 could be moved into the defaults at line 269 as follows:
     components: {
         dragManager: {
             type: "up.LayoutDraggableManager",
             container: "{that}.container",
             options: {
                 listeners: {
                     onDropTarget: {
                         func: "{that}.state.drag.overall.events.onPortletDrag.fire",
                         args: ["{that}.state.drag.data", "{arguments}.0", "{arguments}.1"]
                         }
                     }
                  etc.

This is just an illustration and the style of configuration existing in this file will remain valid for a 
good while. Please don't hesitate to get back in touch with any further questions since I imagine you will 
run into a few other API issues updating to Infusion 1.5 especially in the area of the pager. Do post to 
fluid-work mailing list in case noone seems to be around in IRC.

Cheers,
A