Clarify template references language

[nickwesselman]

https://helix.sitecore.net/principles/templates/references.html

A templates class should never define constants for templates that are not created in the module itself. If a module needs to reference a template or field in another module, it should reference the Templates struct in that module.

This can be read to imply allowing feature-to-feature references. It should be clarified to provide examples of scenarios when this would apply (Feature-to-Foundation, Project-to-Feature).

[nickwesselman]

Thanks @nsgocev for pointing this out.

[lakesol]

Agree the ambiguity should be cleaned up

[anderslaub]

Agree,

On another note; I used to generally recommend to avoid referencing constants or structs directly from dependencies (foundation modules, or features from context) in the original training/workshops.

I generally recommend to keep constants internal in foundation modules. Would be ideal to do the same in features but then these cannot be referenced in views so the pragmatic approach is to let constants be public in features even though they never should be directly referenced by other modules.

If other modules should be able to utilize a constant from one of its dependencies then expose a service class or extension method that perform the tasks where the constant is needed.

For example, the foundation module expose an extension method on an item. Let say item.IsIndexable() where IsIndexable(this item) is an extension method in Foundation.Indexing that simply checks if the item is derived from _Indexable.

Again, this is just an ideal recommendation. Always let pragmatism rule rather than strive for a sometomes utopian ideal.

It is crucial that a string reference to an ID is only ONE place in a solution in the corresponding module. So making these IDs available to dependents through a public constants Templates file is way better than enforcing the consuming modules to repeat the string reference.

Same applies for referencing Sitecore ootb fields. Always use the corresponding FieldIDs struct that Sitecore (in almost all cases) expose for standard system fields.