scripting the resolver with Velocity "Template" attribute defintion

[Peter Schober]

* Brent Putman <putmanb at georgetown.edu> [2017-02-16 03:08]:
> By "fine" I meant "makes sense", in a practical way.  It certainly
> functions without error in all the cases.  Except for the special
> case I mention below, it just doesn't strike me as something one
> could typically practically and reliably use in the
> multi-input+multi-value case.
[...]
> Yes, I misspoke. The ordering is not arbitrary in a technical sense. 
> But the way the values are combined only makes sense if you know and/or
> control the order of *all* the input values. I was trying to convey
> that the ordering is often going to be quasi-arbitrary from the *user
> standpoint*.

That's how I understood it and I appreciate the way of looking at
things.

Not sure I can contribute anything of value at this point.  My
envisaged use-cases all center around "if attributeA exists (and is
not empty/null)" or maybe "if attributeA has this value" then "use its
(or attributeX's) value, elsif something else exists/hasvalueY, etc."
conditionals. The Dependency would reference LDAP DataConnectors as
likely as SQL.

> Fwiw, when I initially started to comment on Peter's suggestion, before
> I got off on the above tangent, I was going to comment/ask: "What would
> it do if the number of values in the inputs is NOT the same?".   I was
> going to say that the only 2 obvious sensible things would be: 1) only
> iterate as many times as the smallest number of values.  This would
> result in some values not being used. This is what Python zip() does.
> 2) iterate as many times as the greatest number of values, and use a
> null/empty value for cases where a specific input's values are
> exhausted.  Neither really seems ideal...  I guess it could also: 3)
> cycle on the inputs which are less than greatest number (treat each
> input like a cyclical "generator").  But at that point my brain starts
> to melt.

For checking if attributeA exists (or has value Y) variant 2 certainly
would be more useful: I'd not miss existing cases (due to some other
attribute having fewer values) and empty/null values don't cause
problems when writing even the simplest conditions in Velocity, i.e.,
#if($attribute) already weeds out empty or null values. You can also
loop over stuff with #foreach, etc. So "padding" would be my naive
preference. I don't claim to understand 3. ;)

Thanks,
-peter