root/tags/v1.0/etc/templating.xml

<!-- Musings on how to define a change flow, using templated changes -->

<!--
    If we have templated changes, then we basically just want to join
    them together using chaining to create a change dependency tree.

    We then wish to apply each change with a dictionary.. actually, an
    iterator which runs over 1..n dictionaries, but applied only to
    that change.

    Ok.. so we have change templates defined. We can name the iterator
    variable for each change based on its name, eg:
    
<change name="change_does_something" type="CommandChange" iterator="%(iter_change_does_something)s">

    This requires us to do substitution processing on the change attributes,
    such as 'iterator' in order to determine the actual iterator to use.
    We then look up the iterator in the namespace available in the
    context above the change.
    
    Ah, bugger, no we can't. Namespaces are defined within the change
    definition itself, so unless we create multiple different namespaces,
    we're not really doing this right.
    
    What we want to be able to do is use the same change template with
    multiple, different iterators, or namespaces. So, we want to be
    able to define a skeleton change template and fill in some of the
    variables elsewhere, by joining the components together.
    
    For example, we might have 2 lists of volumes to be created, one
    on 'device_a', and one on 'device_b'. The list of volumes would
    be defined in an iterator, called 'vol_iter' say; the devices
    would be defined in 2 namespaces.
    
    So we need to be able to do 3 things:
    1. Set the namespace for a templated change at runtime.
    2. Set the iterator for a templated change at runtime.
    3. Use the one change template definition multiple times, with
       different namespaces and iterators.
       
    Let's have a go at defining this mechanism...

    <change usetemplate='template_name' iterator='blah' namespace='blah'/>
    
    While we're at it, we could use a different mechanism from below
    for defining dependencies.
    

    <change>
      <depends on='changename'/>
      <depends on='change2'/>      
    </change>

    Ok. So now we need the difference between a 'change' and a 'changetemplate'.
    Well, there isn't one, except that one is defined via <change/>
    and the other by <changetemplate/>.
    
    Ok, so now we can define a generic change and use namespaces to vary
    which devices it gets applied to thus:

  <target>%(change_specific_target)s</target>

    but how do we specify the prereqs, in order to create our change tree?

    Currently they are defined inside the change template itself, but this
    is not ideal if we want to be able to use a more modular approach and
    define change templates as building blocks and *then* chain them together.

    Namespaces again? No, because we may wish to define multiple prereqs,
    not just the name(s) of a specific number of changes. So, we need a
    mechanism that will be processed after all other stuff is loaded in order
    to build the dependency tree...

    Aha! A dependency tree! That's just XML.. so...

    <dependencies>
      <before changename='change4'>
        <require changename='change3'/>
        <require changename='change2'/>
      </before>

      <before changename='change9'>
        <require changename='change2'/>
      </before>

    </dependencies>

    So, that should take care of post-processing dependency trees.
    If any prereqs are defined within a change template, it will be
    overridden by any post-processed dependencies.
    
-->

<config xmlns:xi="http://www.w3.org/2001/XInclude">


</config>