DataLink inputParam PARAM/@value

[Mark Taylor]

On Thu, 23 Nov 2017, Markus Demleitner wrote:

> Hi,
> 
> On Thu, Nov 23, 2017 at 03:11:45PM +0000, Mark Taylor wrote:
> > 
> > In some library code I'm sketching out now that works out how to
> > invoke Service Descriptor-defined services, I'm currently assigning
> > input parameters into three different groups, according to how
> > their values are acquired at service invocation time:
> > 
> >    - ROW parameters:
> >          value is acquired from a cell of the result table;
> >          a table row object must be supplied to obtain the value
> > 
> >    - FIXED parameters:
> >         value is provided by the parameter definition
> >         and fixed for all invocations
> > 
> >    - USER parameters:
> >         the value must be supplied for each invocation by the user
> > 
> > I'm doing the grouping like this:
> > 
> >    if ( @ref not null )
> >       -> ROW parameter
> >    else if ( @value not null )
> >       -> FIXED parameter
> >    else
> >       -> USER parameter
> 
> This looks like a useful distinction.  But the detection recipe
> you're proposing has the obvious disadvantage that services cannot
> give user-modifiable defaults, which, as said above, I've always
> considered an important use case.  Well, except a few days ago.
>
> ...
>
> After the discussions of the last few days, I'd say that we're not
> really ready to define a "don't change this" signature for Datalink
> PARAMs.  I hence think the best we can do without an ugly hack is
> 
>     if ( @ref not null )
>        -> ROW parameter
>     else if ( @value not null )
>        -> USER parameter with filled-out default  (probably mandatory)
>     else
>        -> USER parameter without filled-out default (probably optional)

It's not much different from what I suggested, given the caveat from
my message:

On Thu, Nov 23, 2017 at 03:11:45PM +0000, Mark Taylor wrote:

> This arrangement doesn't prevent the application code from filling
> these parameters differently, e.g. giving the users the option to
> change ROW or FIXED parameter values at invocation time; so the
> ROW and FIXED values can be viewed as defaults.  I'm currently

Except your formulation does sort of presuppose user interaction.
At least one scenario I am expecting is a DataLink with all
parameters filled out to give a fixed link URL for each row,
and no expectation that the user needs to see or supplement
the supplied values.  That would correspond to all ROW/FIXED
in my terminology or all ROW/USER-with-filled-out-default in yours.
But I think the only difference here is wording.

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/