[lnst trac] #20: suggestion: add suppport for dynamic template functions

[fedora-badges]

#20: suggestion: add suppport for dynamic template functions
-------------------------+-----------------------
 Reporter:  olichtne     |       Owner:  somebody
     Type:  enhancement  |      Status:  new
 Priority:  major        |   Milestone:
Component:  component1   |     Version:
 Keywords:               |  Blocked By:
 Blocking:               |
-------------------------+-----------------------
 Template functions could be dynamically loaded in a similar way to how
 Tests are loaded. We could create a new directory e.g. Functions/ where
 they would be located. I discussed this with Jirka when we talked on the
 topic of directly using python commands in the recipes. It would also make
 template functions more universal and flexible.

 Implementation of this shouldn't be too complicated. But the more
 important question is how could this be used. The problem I see here is
 that currently template functions are used to access internal data of the
 controller. However the dynamically loaded functions shouldn't be able to
 do this because they either wouldn't see the internal data structures or
 it would be too confusing if they somehow did.

 If you have any suggestions/ideas of use cases or on the other hand you
 think this is a bad idea please add a comment.

-- 
Ticket URL: <https://fedorahosted.org/lnst/ticket/20>
lnst <http://example.org/>
My example project

[fedora-badges]

#20: suggestion: add suppport for dynamic template functions
--------------------------+----------------------
  Reporter:  olichtne     |      Owner:  somebody
      Type:  enhancement  |     Status:  new
  Priority:  major        |  Milestone:
 Component:  component1   |    Version:
Resolution:               |   Keywords:
Blocked By:               |   Blocking:
--------------------------+----------------------

Comment (by rpazdera):

 I personally think, that this is very good suggestion. IIRC we did stumble
 upon the idea of making that function set extensible at some point.

 The problem with internal controller data could be resolved by introducing
 some additional API for the functions. The controller would indicate
 (somehow), that it wants to make some specific data/variables available to
 the user-defined scripts/functions. And they could access them.

 The area of accessing the recipe from the XmlTemplates is a little bit
 gray at the moment. In the case when the controller explicitly makes some
 data available, we wouldn't need to worry about the parsing chicken-egg
 conflicts any more. We would simply print out "The data you're requesting
 are not yet available. Go fix your recipe."

 I'd definitely like to discuss this further!

-- 
Ticket URL: <https://fedorahosted.org/lnst/ticket/20#comment:1>
lnst <http://example.org/>
My example project