Hi, Antranig: I think escaping is fine in this case. I would prefer to use encodeUriComponent() or something broader spectrum rather than escaping a specific character by convention, but I could be convinced as long as we are consistent and document the convention well.
Speaking of which, as I was a bit surprised by this requirement (even if it should have been obvious), I went back to the docs to review in depth. This topic seems to need a bit of fleshing out. The "IoC API" docs indicate that dots are not allowed in member names <http://docs.fluidproject.org/infusion/development/IoCAPI.html#fluid-typenametomembername-typename->, but neither the "IoC Reference" docs <http://docs.fluidproject.org/infusion/development/IoCReferences.html> nor the "How to use Infusion IoC <http://docs.fluidproject.org/infusion/development/HowToUseInfusionIoC.html>" docs are clear enough about this requirement. We ourselves even encourage the use of keys with dots in namespaced listener definitions <http://docs.fluidproject.org/infusion/development/InfusionEventSystem.html#namespaced-listeners> . Does this mean we can never use distributeOptions to distribute alternative namespaced listener definitions, for example, to clobber a default event listener with a func of fluid.identity? I have done this repeatedly in my own work, but have only tried it with nested component options. I'm hoping distributing a generic event with the right namespace would replace an existing namespaced definition, but would like to confirm for future reference. Anyway, back to my main question: Is there an option to add support for escaping characters in an IoC reference? If not, or if it's too much to consider, we should at least better document where dots are allowed (only in namespaced event listener definitions? not even there?). If we can't or won't change this, it would also be helpful to add a warning, just as we have done for other non-obvious things like fluid.viewComponent needing to be on the right-most side of the gradeNames chain, missing out "events" in referring to a component event, et cetera. Cheers, Tony On Fri, Apr 14, 2017 at 6:31 PM, Antranig Basman < [email protected]> wrote: > Thanks for these very helpful suggestions. It is great to have our use of > JSON schema reviewed for compliance with the developments in it since we > originally based our work on it in 2011. I should note that the use of > propert names containing periods such as "fluid.prefs.textSize" or > "#fluid.prefs.textSize" is problematic with the current version of Infusion > - if these appear in IoC references, the periods will be interpreted as > property indirections, making it impossible to reference either these > properties or anything nested within them. Our practice has been to escape > these either explicitly, using the "\." syntax, or else in an implicit way > by replacing them with underscores "_". Do you have a preference between > these, or any other alternative suggestions? > > Cheers, > > Antranig > > On 14/04/2017 10:03, Tony Atkins wrote: > >> As agreed in the PCP API meeting, I have been reviewing the "primary >> schema" wiki page for the preferences >> framework: >> >> http://docs.fluidproject.org/infusion/development/PrimarySch >> emaForPreferencesFramework.html >> >> First of all, although I recognize that this is an example, it lacks some >> pretty basic context. The example >> does not make use of the "/$schema/" field >> <https://spacetelescope.github.io/understanding-json-schema/ >> basics.html#declaring-a-json-schema>, and as >> such there is no indication of the fact that this is even a JSON schema, >> or of what version of the standard >> we are using. This should be addressed. If for example our "/$schema/" >> field indicated that our schema was >> written to work with draft v3, it might still reasonably expected to work >> with validators that support newer >> versions. >> >> The next biggest thing I notice (as their use is not valid in the root of >> a schema) is that the example >> field definitions are "snippets" of schema content rather than a valid >> schema. I'm not arguing that every >> example has to be a complete schema, only that we mention the context in >> which an examples would be used. >> >> So, I'm assuming these snippets belong in either the "definitions >> <http://json-schema.org/latest/json-schema-validation.html# >> rfc.section.5.26>" or "properties >> <https://spacetelescope.github.io/understanding-json-schema/ >> reference/object.html#properties>" block of a >> schema. As mentioned in my note to Steve, even if the goal is to >> describe the fields that are accepted in a >> particular document type (AKA "properties"), defining the fields in a >> "definitions" block gives the best >> options for reuse. As I also mentioned in my note to Steve, my advice is >> to make use of the "id" field, as >> shown in these examples <http://json-schema.org/latest >> /json-schema-core.html#rfc.section.8.2>. Combining >> all of the above, the main definitions file might look something like: >> >> >> { >> "$schema": "http://json-schema.org/schema#";, >> "id": "http://real.site/schemas/preferences.json";, >> "definitions": { >> "fluid.prefs.textSize": { >> "id": "#fluid.prefs.textSize", >> "type": "number", >> "default": 1, >> "min": 1, >> "max": 2, >> "multipleOf": 0.1 >> }, >> // Remaining defs omitted for brevity >> } >> } >> >> >> Although "/id/" values are not strictly required, using them gives us a >> simpler way to refer to a definition >> from another file. If we are dealing with a file in the same directory >> (hosted or local), we can now either >> refer to "/preferences.json/definitions/fluid.prefs.textSize/" (the path >> relative to the root of the >> document) or "/preferences.json#fluid.prefs.textSize/" (the "/id/"). >> Within the preferences.json document >> itself, once we have "/id/" values, we can use references like >> "/#fluid.prefs.textSize/", which seems >> closest to our use of namespaced grades in other contexts. >> >> Even within the snippets, I can see that we are using an older version of >> the standard. This example has >> also been updated to reflect the need to use "/multipleOf >> <https://spacetelescope.github.io/understanding-json-schema/ >> reference/numeric.html#multiples>/" instead of >> the earlier "/divisibleBy/", as discussed in the meeting. >> >> I'll stop there, as I think just looking at the examples highlights >> enough for a single note. I also plan >> to review the JSON schemas (or snippets) in various repos and will >> comment under separate cover. >> >> Cheers, >> >> Tony >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> http://lists.gpii.net/mailman/listinfo/architecture >> >> > _______________________________________________ > Architecture mailing list > [email protected] > http://lists.gpii.net/mailman/listinfo/architecture >
_______________________________________________ Architecture mailing list [email protected] http://lists.gpii.net/mailman/listinfo/architecture
