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
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
