Difference: DpHipeTools (99 vs. 100)

Revision 1002012-11-30 - JavierDiaz

Line: 1 to 1
 
META TOPICPARENT name="WritingTasks"
<-- ANALYTICS CODE - DO NOT EDIT -->
<-- Google Analytics script BEGIN -->
<-- Google Analytics script END -->
Line: 88 to 88
  For your task to appear in the Applicable category whenever the user selects a suitable variable, you still need to define a Validator. See Validating prime input below.
Changed:
<
<
Warning, important Tasks without at least an input cannot be registered and should not be used (create a parameterless function instead).
>
>
Warning, important Tasks without any input cannot be registered and should not be used (create a parameterless function instead).
 

Tasks Naming Conventions

Line: 199 to 199
 If no specific modifier fits your task parameter, the default modifier will be used. The default modifier only has a dot to drop variables. Others modifiers include an editor at the right of the dot to enter values. You can implement a custom Modifier and register it in the system to be used whenever a parameter of the registered type is used. You can also write your specific Modifier for any of the already registered types. In that case, you can create and assign your modifier (and listeners ....) to your parameter in Task.getCustomModifiers() see Registering a modifier.

Warning, important NOTE:

Added:
>
>
Warning, important NOTE:
 The following behaviours and limitations are present in the provided modifiers:
  • Not all modifiers are registered: for example if your parameter is of type String but will represent a file (path) the system will choose just a JStringModifier, so you will have to explicitly associate your parameter (name) to a JFilePathModifier- in Task.getCustomModifiers(). * Also, if you want to tweak a (registered) modifier (using a specific constructor, for example) you will also have to use Task.getCustomModifiers()
Changed:
<
<
  • While you can always write SomeTask(param = null) on the command line, using a task dialog you will just get SomeTask(): modifiers use null to signify that they have no value and task command generation interprets this as "not using this parameter".
  • Modifiers have no notion of the optionality of parameters: if they have a valid value, they will return it. Task command generation for GUIs will not generate a parameter assignment if the value equals the default. See Task Preferences to change this default behaviour.

  • Modifiers will mark as erroneous any variables incompatible with the type (dynamically), but will accept not reject dropping it in the dot.
  • If you want your parameter to support dropping a set of variables (multiple selection in Variables View) your parameter must be of type java.util.List (or Object). [Note that list or Pylist will not work]
  • Modifiers have no notion of default values. This implies that there is no way to know what command will be generated seeing a GUI unleSee the next section
>
>
  • While you can always write SomeTask(param = null) on the command line, using a task dialog you will just get SomeTask(): modifiers use null to signify that they have no value and task GUI command generation interprets this as "not using this parameter".
  • Modifiers have no notion of the optionality of parameters (or default values): if they have a valid value, they will return it. Task command generation for GUIs will not generate a parameter assignment if the value equals the default. See Task Preferences to change this default behaviour.
  • Modifiers will mark as erroneous any variables incompatible with the type (dynamically) and validator, but will neither reject nor remove any variable dropped
  • If you want your parameter to support dropping a set of variables (multiple selection in Variables View) your parameter must be of type java.util.List (or Object). [Note that list or Pylist will not work: this may be obsolete since Jython 2.5?]
 

Showing default values
 
This site is powered by the TWiki collaboration platform Powered by Perl