I think that yzen's branch for FLUID-4686 reforming UIOptions' Store grade at
https://github.com/fluid-project/infusion/pull/323/files is nearly ready to go, but it has exposed some
global naming issues with our reworking of the component.
An overall aim of this refactoring has been to produce a set of base grades which are "empty" so from the
point of view of our integrators (3rd parties) they have the ability to start from an empty canvas as
regards building new configurations of UIOptions.
It has been our practice to give the name "default" to those particular "filled" grades which represent what
we have come to call the "out of the box" configuration of UIOptions, representing its default panels and
settings.
For example, for the component still named "fluid.uiEnhancer", this grade itself now contains no
settings-specific material, and these definitions have been moved to a grade named
"fluid.uiEnhancer.defaultActions".
Similarly, for the component still named "fluid.uiOptions", this grade is empty, and all definitions for the
built-in panels have been moved into "fluid.uiOptions.defaultSettingsPanels".
This kind of convention seemed to work reasonably well until we got to the grade already named
"fluid.uiOptions.defaultModel" created in the FLUID-4686 branch. For this grade, the meaning of the word
"default" refers to "the default state of the UIOptions model for a particular configuration, before the
user has modified any settings", rather than the meaning of "default" in the cases I cited earlier, where it
means "the particular configuration of UIOptions that comes 'out of the box'".
By analogy with the above grades, we need a default "empty" version of the "defaultModel" grade which would
seem to involve a confusing further use of the word "default". As the branch stands, the "empty" grade is
named "fluid.uiOptions.defaultModel" and the "filled" grade is named
"fluid.uiOptions.defaultModel.outOfTheBox" which is descriptive but breaks the pattern of the previous examples.
I'd like to ask the community for comments and suggestions on this issue, as well as the general issue of
the level of API compatibility we are committed to for this release. My understanding is that since
UIOptions has so far only reached "preview" release status, we are not overly concerned with breaking API
changes where they are well-motivated. One particular issue which comes to mind is the renaming of the
UIOptions Store method from "fetch" to "get" and "save" to "set" as more conformant with the DataSource API
we have established elsewhere (for example, in the GPII and CSpace).
Cheers,
Antranig
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
