For flexibility one could specify a "NeverWillActuallyBePassed" value
as the default value of the parameter, then check for this value and
issue error messages.
Or, define the type of the parameter as a union of the desired type
and an (your defined) "error type" and specify the default as a value
having the error type. This is similar to the above approach, but is
more general and won't require the developer to invent a multitude of
NeverWillActuallyBePassed values for each possible type.
Cheers,
Dimitre
On Wed, Oct 15, 2014 at 10:00 AM, David Sewell dsewell(_at_)virginia(_dot_)edu
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Right... and actually that's probably the only way to provide full custom
diagnostics in a case where you have more than one required parameter,
because with @required="true" the first missing parameter will trigger a
run-time error and the subsequent ones won't be checked.
So it's probably not that useful a potential feature to enable a custom
message on error for required stylesheet parameters.
David
On Wed, 15 Oct 2014, Eliot Kimber ekimber(_at_)contrext(_dot_)com wrote:
Make the param not be required and then check for it in a root template.
Cheers,
E.
—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com
On 10/15/14, 11:19 AM, "David Sewell dsewell(_at_)virginia(_dot_)edu"
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Given a stylesheet parameter <xsl:param name="somevar" required="yes"/>,
failing to supply a parameter value at run-time results in a boilerplate
error
message such as "XTDE0050: No value supplied for required parameter
somevar".
It would be helpful to be able to supply a custom error message such
as "required: somevar=[true|false|unknown]" to save the user the time it
takes
to look through the code to figure out what parameter is expected.
There's no
way to do this in the XSLT spec through 3.0, correct? and no common
extensions
for doing it?
If not, would that be a useful feature for others, or are there reasons
not to
implement something like that as an extension or enhancement?
David
--
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell(_at_)virginia(_dot_)edu Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/
--
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell(_at_)virginia(_dot_)edu Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--