Currently inline injection in topics is allowed and processed. We need a system of enabling/disallowing inline injection. It is set in three places: 1. SERVER Server behaviour: Specified in the server configuration. This can be set to "Inline injection:strict" and "Inline injection:fascist". Strict will disable inline injection unless it is requested by the content spec or by the client. Facist will simply not do it, no matter what. So by default the server will not do inline injection. It must be requested explicitly by the Content spec or the client. 2. CONTENT SPEC New Content Spec parameter: Inline Injection: Request|Disallow 4. CLIENT COMMAND LINE --inline-injection
Further refinement: In strict mode we need an optional list of topic types that are allowed to have inline injection. This allows us to mandate that only certain topic types can have inline injection. So in fact, we should have the following three server behaviours: Permissive Inline injection is performed for all topic types if the Content Spec or the client request it. Strict Inline injection is performed if requested, but only for the list of specified topic types (configured on the server, or passed as a comma-separated argument list from the client) Fascist Inline injection is never performed, no matter what Inline injectoin
The Strict behaviour list should be able to be specified in the Content Spec as well.
Added. There are 4 server states possible: Permissive, Strict, Fascist and On. If nothing is specified then the server defaults to Permissive. The three states work as defined above and On will always process the injections no matter what. With on, you can however still use strict modes through the client or content specifications. If the injections are ignored then they are left as comments within the XML data. The server settings that are required are as follows: <property name="csprocessor.injection-mode" value="strict"/> <property name="csprocessor.injection-types" value="Task, Reference"/> The injection types doesn't have to be specified as it is only used with strict processing mode. These settings should be placed in the <system-properties> section of servers standalone.xml file. Content specs have three states that can be specified (Off, Strict and On). Strict is an implied state however. The inline Injection tag isn't a mandatory tag. Any topic types that are specified are checked to make sure that they are a Topic Type. The format for including these states in a Content Spec is as follows: On State: Inline Injection = On Off State: Inline Injection = Off Strict State: Inline Injection = On [Concept] These states follow the same as the server states where on is the same as permissive or on, Off is the same as fascist and Strict is the same as strict. The client has the same three states as a content specification however uses different syntax. The commands that can be used are found below. These aren't validated to make sure the variables set are Topic Types, however if they aren't topic types then they are simply ignored. skynet build <ID> --inline-injection skynet build <ID> --inline-injection=on skynet build <ID> --inline-injection=off skynet build <ID> --inline-injection --injection-types=Reference,Concept,Task,Overview The state that is chosen depends primarily on the server state. So if fascist is selected then no injection is done. If permissive or on is selected then it can be upgraded to strict or off by the client or content specs. If a content spec has a level of on and the client uses a strict command the strict command will have priority and vice versa if the content spec had the strict state. The strict Topic Types that are compared to are any types that are specified on the server, via the command line or in a content specification. For example if I had Reference and Task on the server and then specified to do Concepts via the command line. The builder will process injections for all three topic types. All validate and push commands will use the server on setting since these are primarily used to check content and are in general un-related to content specifications.
I'll release the current state into version 0.17.0. However should a warning be placed in the Compiler Errors & Warnings chapter if a topics injection gets ignored?
Lee, yes a warning should be included.
Due to the changes with Bug #798842 at version 0.22.0. The warnings should now no longer be required as it will be entirely up to the user to turn off the injections. If not move this back to assigned and I'll add the warnings.