Since my last post I managed to implement the feature “parameter binding for context orientation”. If this sounds gibberish to you, as it was for me when I’ve first heard it, I will explain it in detail.
It’s actually a simple thing. Let’s say you don’t want to set certain types of input parameters of your web services manually since they are already known due the knowledge of a certain context which already defines these parameters “out of the box”. So let’s say you know you’re dealing with data which is connected to e.g. the United States of America. An appropriate context for this would be “country” or just “location” or any other name which sounds good to you. The plugin will let you choose an arbitrary context name but in this example I will just stick with “location”.
A context can have several instances – in our case the instance is “Unites States of America” or just “US”.
To encode this information inside a webpage, I decided to use the well known tag instead of a custom microformat, since it already fits our needs perfectly and is furthermore a wide used standard for meta information.
Simply put, the context is described with the following html code:
Some parameters, which can easily be derived from this concrete context instance, would be: currency (–> US Dollar), national language (–> English), total area (in km²) (–> 9826675), date-format (–> m/d/yy), the calling code (–> +1) and many more.
I’ve mentioned that this feature comes out of the box, well, nearly. As for now, you have to insert these context values by yourself – but only once of course, otherwise it wouldn’t be of any use . For proper use, just imagine an already existing full fledged registry of such context values customized to your needs.
Basically you can store any arbitrary values in this registry, also more abstract ones like e.g. security parameters – with the context “security-level” and instances of “low”, “middle” and “high” where each of them defines common parameters in a different way (like scheduled-scanning is set to “on” or “off”, or at which intervals a scheduled scan is performed).
Here you can see the dialog where you can manage your context values like creating/deleting a whole new context. Inside a certain context, many different instances can be created/deleted like “AT” for Austria or “DE” for Germany if we stick with the “location”-example. And inside a certain context and instance of this context, the values can be set and therefore used in the micro service workflow.
To indicate that a parameter shall be filled with a certain context/default value, its content must be filled with (“the global variable”) “$context” first to let the engine know that this variable shall be substituted with the correct value according to the used context instance.
results, if the instance is properly set, in
I’ve decided to directly manipulate the DOM of the webpage (so that users actually see the substituted values) rather than use the values only “inside” for processing usage, as it is supposed to be I guess. So in a first step, the DOM will be updated with the context values and after that invocation instances can be executed, where the parameters are already set and can be directly read from the html file. By this, the workflow engine didn’t need to be changed at all so far.
Some info about my implementation:
So I just store them inside the Firefox preference system (like the web service endpoints) using a tiny more complicated separation syntax than the usual “.NEXT. and .ITEM.”-strategy in order to also encode contexts and instances next to the ordinary entries.
Nevertheless, I did use localStorage for another purpose – the mapping between the name of the parameter which needs to be filled with a context value and the context itself. I need such a kind of mapping, since I only know the name of the parameter during the parsing process. The information in which context to look at isn’t given in the workflow and traversing all the different entries of the registry during page construction (as mentioned before, context values are substituted right after the page is loaded) would slow down the whole process and therefore affect user experience.
So I use the localStorage in this way (when we stick with the above example):
currency –> location
national-language –> location
and so on…
and therefore I can access/substitute context parameters in a pretty fast manner. Key-names are of course prefixed with a unique identification since I don’t want that other plugins/script-code accesses/manipulates this data accidently. So actually entries are encoded this way:
extensions.webservicemashup.contextmap.currency –> location, and so on.