Here we are again.
Since my last post, which discussed the topic about default values resp. parameter binding for context orientation, I’ve spent time thinking about how ordinary variables can be introduced to make the workflow more flexible and easier to use for more complex stuff like building loops of web service invocations.
It was clear that embedding a whole programming language into a microformat would be too complex and actually not of any use because there are far better ways to do this like JSP/JSF.
So I focused on defining and using variables on a small scale to get the whole thing work in a usable way.
First of all I had to make a decision about how many resp. which scopes to introduce for variables. When we look at an ordinary workflow, we can see that an invocation instance is a kind of module. It expects certain input parameters and produces an output. So it was obvious to me that there should also be an instance scope where variables can be defined and used only inside this instance – comparable to local variables of ordinary programming functions/methods.
The next “higher” scope is the page scope. Variables defined on top of the page resp. outside of any invocation instance can be accessed throughout the entire page – whether inside an invocation instance or not.
The last scope is the global scope, where variables defined in this way can also be accessed on other pages. They get defined the same way as page-variables (outside of an instance), with the only difference that they are marked as global.
So we have three different scopes: instance-, page- and global scope. In case that multiple variables of different scopes have the same name, I’ve implemented the resolution in a bottom-up style which is also the case in common programming languages. Variables defined in a smaller scope “overwrite” variables in a higher scope as long as the smaller scope exists.
Since variables should be used to control the workflow and not to build complex data structures (which can/should be done inside the invocated web service), only primitive datatypes can be defined. Since the plugin is written in javascript, we can sum it up to 2 different types: strings and numbers whereas the former one is indicated by quotes.
There can be made any arbitrary calculation with variables (and also constants of course) since the eval() function of javascript takes over the evaluation.
Here is an example how variables can be used right now.
First of all the definition where you can determine the scope of the variable(s):
So there is a global variable named anyVariableName and 3 variables with page scope named i, j and k.
And then some calculations:
The assign-tag indicates that a variable assignment is going to take place. For the assignment itself, I’ve decided to use the abbr-design pattern which is described on microformats.org. So if you have some values on your html page which need to be machine-readable (and not only human-readable) like “5.000,00″, you just put the machine-readable value “5000″ inside the title attribute. As you can imagine, the class name is the destination variable.
All these things seem to work fine so far but I haven’t embedded them in the workflow yet because I still need to finish some tests on my components.
The next topic to talk about is the time when to reset variables, complex variables which can be handed over and received to/from web services and maybe some more implementation details.
So long! Tom