Dynamic loading of fragments

[roleyfoley]

Current Behaviour

Fragments provide access to the hamlet engine for users and can be added as part of a CMDB. They are currently implemented as case statement which is assembled as part of the CMDB composite loading process. For each component this case statement is executed and if the fragment id matches the statement the fragment details are executed during the component processing.

While fragments do provide a powerful way to modify your solution to meet the needs of a specific solution their processing is inefficient ( the case statement gets longer and longer ), brittle ( a break in one fragment breaks the whole process ) and they can't be shared or loaded through our dynamic loading processes ( the freemarker file with the case statement is built outside of the engine ) As a result of this they can't be included in Scenarios #1426 which supports including all other input data except for this

Expected Behaviour

• To be able to define documented details on a given fragment, and to execute the fragment as an isolated function for a given component ( i.e. the component will only call the macro that is has been told to )
• Fragments can be offerred by CMDB's and Providers
• A component can invoke multiple fragments
• Components can define supported component types which will be checked to ensure fragments are appropriate for a component

Possible Solution

• Define a loader process inline with our dynamic loading process, the load process should support loading from CMDB or providers
• A component will be able to control the location through its configuration of the component ( must include a provider with a special _cmdb provider to load from a local cmdb ). This reduces the risk of name collisions
• A fragment is defined as a function, the function will receive a _context and occurrence parameter and is expected to return the _context after it has been appropriately modified
• To implement a fragment, the fragment developer will need to include an addFragment macro which defines the macro and its parameters and also then include the function definition itself

Context

This would align fragments with the rest of our function loading processes and also provide documentation and context to fragments

[RossMurr4y]

Does the name Fragment still match this then? I like your suggested solution, but Fragment sounds like it was named after the "which part of the case statement do you want to run" whereas this new function - that accepts a context and outputs a context - is more of a "context transformation".

Of course they do the same thing but if I was just learning Hamlet, I can't infer much from "Fragment" but something with "Context" in the name that indicates pre-processing context manipulation would allow me to apply pre-existing knowledge from other languages on to this feature.

[ml019]

A fragment can basically do anything, as @roleyfoley has ably demonstrated.

The name came from the idea of a code fragment - a part of the configuration process but not all of it.

Maybe "snippet" might make more immediate connection for the reader?

[roleyfoley]

We had thought of using snippets for deployment profiles/policies and I think that fits better in that name. I.e. snippet is tiny module ( module covers a whole blueprint where a snippet just covers a components configuration )

Maybe Fragments might be better as Extensions, they do extend the functionality of a component unlike a snippet or a module which implement existing configuration, just in a standardised pattern

[ml019]

+1 for extensions. Yet another rename but easier to handle in the freemarker world.

[RossMurr4y]

Sounds like we're on to a winner then :)

[ml019]

@roleyfoley I think this can be closed?