Workbench Exploration

Home > Books > Tutorials and Training Guides > Getting Started > Workbench Exploration

Workbench Exploration

The workbench comes with some pre-installed demonstration scripts. This section will explore the pre-installed scripts to illustrate the NetKernel system and to get you familiar with using the workbench for rapid prototyping.

The hello world section explains where the workbench is physically located and how browser requests to the workbench cause scripts to be executed.

DPML Examples

In the previous section it was shown that DPML is a simple scripting language for issuing URI requests in NetKernel. The sub-directory example_dpml/ in the workbench contains some pre-installed DPML example scripts.

To refresh your memory the helloWorld.idoc is duplicated there. You can run it by requesting this URL http://localhost:8080/workbench/example_dpml/helloWorld.idoc.

Simple XSLT

The basic_xslt.idoc script shows how the XSLT transform service can be called to apply an XSL stylesheet to an XML document...

<idoc>
  <seq>
    <comment>
    *****************
    Execute an XSLT:
    *****************
    </comment>
    <instr>
      <type>xslt</type>
      <operand>myfirst_data.xml</operand>
      <operator>myfirst_transform.xsl</operator>
      <target>this:response</target>
    </instr>
  </seq>
</idoc>

You can run this by requesting this URL http://localhost:8080/workbench/example_dpml/basic_xslt.idoc. You can see that myfirst_data.xml is some simple colour data and the xslt transforms it into an HTML table.

When run the DPML instr is turned into the full active URI request to the active:xslt service...

active:xslt+operand@ffcpl:/example_dpml/myfirst_data.xml
+operator@ffcpl:/example_dpml/myfirst_transform.xsl

Notice that the relative URIs of the myfirst_data.xml and myfirst_transform.xsl in the DPML instruction are resolved relative to the URI of the dpml script. ffcpl: is the URI scheme used to address resources in NetKernel modules - for the time being you can think of it just like the file: scheme.

Why not modify helloWorld.idoc to source the active:xslt URI directly. Do you get the same result?

Multi-Step Processes

Included in the example_dpml/ directory are some other XSL transform which can be used as filters on the myfirst_data.xml to select a single colour. What do you think will happen with the following script...

<idoc>
  <seq>
    <comment>
    *****************
    Two Stage XSLT using a direct active URI
    *****************
    </comment>
    <instr>
      <type>xslt</type>
      <operand>
        active:xslt+operand@ffcpl:/example_dpml/myfirst_data.xml
            +operator@ffcpl:/example_dpml/select_red.xsl
      </operand>
      <operator>myfirst_transform.xsl</operator>
      <target>this:response</target>
    </instr>
  </seq>
</idoc>

You can run this by requesting this URL http://localhost:8080/workbench/example_dpml/two_stage_transform.idoc.

Can you see that the active URI specified in the operand argument filters the red data. But since this active URI is itself just a URI addressable resource then it can be transformed by myfirst_transform.xsl into the table layout you have seen before. This is a small example of how NetKernel's active URI address space can be used for functional programming. Try changing the transform to select_green.xsl?

It was stated previously that writing active URIs longhand is not desirable - so DPML lets us use variables and multiple instructions. The following DPML script gives the same result as the last but is more readable...

<idoc>
  <seq>
    <comment>
    *****************
    Two Stage XSLT using a DPML variable.
    *****************
    </comment>
    <instr>
      <type>xslt</type>
      <operand>myfirst_data.xml</operand>
      <operator>select_green.xsl</operator>
      <target>var:colour_filtered</target>
    </instr>
    <instr>
      <type>xslt</type>
      <operand>var:colour_filtered</operand>
      <operator>myfirst_transform.xsl</operator>
      <target>this:response</target>
    </instr>
  </seq>
</idoc>

You can run this by requesting this URL http://localhost:8080/workbench/example_dpml/two_stage_transform2.idoc.

Services that run Scripts

So far you have seen how scripts in the workbench are executed when they are requested. In fact the workbench is configured so that the file extension of the requested script creates an active URI request to a service to run the script. All scripts are run by issuing an active URI request to a service dedicated to executing a specific language, Here's an example that shows how one DPML script can call the DPML runtime service to execute another script...

<idoc>
  <seq>
    <comment>
    *****************
    Hello DPML Language Runtime:
    
    Here we issue a request to the DPML language runtime to execute the script
    basic_xslt.idoc
    *****************
    </comment>
    <instr>
      <type>dpml</type>
      <operand>basic_xslt.idoc</operand>
      <target>this:response</target>
    </instr>
  </seq>
</idoc>

You can run this by requesting this URL http://localhost:8080/workbench/example_dpml/helloDPMLRuntime.idoc.

This pattern for executing scripts by language runtimes is used to execute all languages on NetKernel - in fact you used this same pattern earlier to execute XSL transforms in the XSLT language runtime. The later tutorials will show the use of other more traditional scripting languages.