task=B pretask=makeAServerdown posttask=checkBServer
[download]

use strict;
use warnings;
use Data::Dumper;

sub makeAServerdown
{
print "AHA:", @_, "\n";
}

my $line = 'task=B pretask=makeAServerdown posttask=checkBServer';

my $h = { map { my ($k,$v) = split /=/; $k=>$v } split (' ', $line) };

print Dumper $h;

{
  no strict 'refs';
  $h->{pretask}->($h->{task});
}
__END__
$VAR1 = {
          'pretask' => 'makeAServerdown',
          'task' => 'B',
          'posttask' => 'checkBServer'
        };
AHA:B
[download]

Hi vsespb, Thanks a lot for sharing your suggestions. I am not sure, if I understood the way you are integrating tasks and customizations but it seems following:

1) $h (hash) so used in your file(should be standard file?).

2) the module should be then included in task side code where the $h o
+f this module will be read.
[download]

Advantage seems to be that xml parser overhead is not required. but then again xml/text have their own pros and cons.

Some concerns:
1) are you suggesting reading this : "task=B pretask=makeAServerdown p
+osttask=checkBServer" from some text file. or hardcoding in code? I a
+m assuming text file for now.

2) The customizations suggested by you will work if only known action 
+is being called. But my use case is that user can customize with anyt
+hing they like i.e. they can maybe add any code block they want etc.
 example of code block: (simple example here)

for (int i=0;i<10;i++) {
print('just a block for fun: ' . $i . "\n");
}
[download]

Kindly look into this and please correct me as required.

1) are you suggesting reading this : "task=B pretask=makeAServerdown posttask=checkBServer" from some text file.

yes

2) The customizations suggested by you will work if only known action is being called.

yes

If you need arbitrary code execution, write an API for programmers.

I don't see any reason mixing API for programmers and for normal users, nor I don't see use of XML/other formats in API for programmers.

Or, parhaps, I misunderstand the OP.

I certainly would not use XML for that. XML is useful for things like communications between different systems or storing some configuration into a file on disk, it is really unpractical as an internal data structure.

You probably want to build a graph, which could be possibly a hash of arrays, in which the array contains all possible successor nodes to the hash key node. Or you could build a list of possible complete paths from a given node.

Your description:

1) A->B->C->D
2) A->C->D
3) A->B->C
4) A->D
[download]

is not completely sufficient to figure out the paths that are allowed. Suppose that I am on node B: does that mean that we can go to node C irrespective of what happened before (in which case paths 1 and 3 seem to be redundant), or that I am allowed to go to C only if I was on A before getting to B (so that I can't go anywhere if I am on node B but not coming from A)? Determining the best modeling for your application behavior depends on an answer to such questions.

Hi Laurent, Thanks a lot for looking into this.

Yes true xml are not used for such code mix but it would be kind of configuration file only right? as it holds details related to tasks. exampple: should a task be executed or not and if yes than with what configuration parameters. The only extra thing I was thinking of adding was the pre/post tasks which may vary for some users. (also idea of this post is to come up with some good design to handle the use case.)

Regarding the building graph/hash suggested by you, I had considered that but I was not convinced with the idea because doing that means I am kind of fixing the flow of tasks. Any changes in future require update of code rather than just a tiny update in xml/properties file which can be even exposed to user. (i generally prefer xml/properties file compared to such code updates because of more flexibility and ease of use. As end user may not know the code and can just update the xml file to change/control the flow.)

Just to let you know that mixing xml/perl is not the best design and that's why I am looking for inputs here. I wanted to check if people were using it or apis are for this. (note: jsp/jsf mix html and java. so thought something on those lines.)

Regarding paths: 1) A->B->C->D 2) A->C->D 3) A->B->C 4) A->D

These are just for example, you can check the xml file shared in my first post. note its rough design and any such redundancies will be handled when we actually finalize an approach.

regarding the details requested by you. I am updating original question with a real life example. Please check, hope it helps in understanding the case more.

Hmm,

there are many aspects to be taken into account.

I was writing last week a program template aimed at some other IT persons. The idea was to give them the (quite complicated and thoroughly tested) algorithm, and let them construct the input data, which could be summarized as follows:

('table1' => { 'index_fields' => [0, 1, 2], 'ignored_fields' => [6]},
 'table2' => { 'index_fields' => [2], 'ignored_fields' => [4, 7]},
)
[download]

It is not too complicated to give IT persons instructions on how to fill the next records in this structure to achieve the desired result.

But if your user has no IT background, this might not be workable.

I still don't think that asking them to fill an XML structure is the right idea. Asking your users to write a config file such as:

1. A -> B -> D

is clearer for your user (so long as you explained the details) and actually easier for you to parse.

List of rout elements:
This would look like:

WSID	Work_Station_Name
1(unique int)	buildFrame
2(unique int)	addSeats
3..	...

List of existing routs:
would look like:

RID	Rout_name	WSID_1	WSID_2...
1	Model_1	4	2...
2	Model_2	7	3
3	Model_3	7	4...

What your storage solution is does not really matter. Could be text files, XML, RDBMS, JSON, .ini....whatever...

The key is to be able to easily add "workstations", and easily add routs(ordered collections of workstations)

The workstation list is just a lookup to fill in the rout. Both the existing routs and workstation list would only be added to. (thus you never loose the history of a rout).

Really all you need is an array to hole the workstations and a hash of arrays to hold the routs. With those two structures, you can do pretty much anything you need to do for a simplistic system. Both lists could be stored in a single file if that makes it easier, or in a spreadsheet assuming you use something like Spreadsheet::WriteExcel.

I would use an RDBMS for my storage personally, but again, it hardly matters. In my experience, the priorities are in order:

1. flexibility(mfg always changes)
2. Maintainability (KISS)
3. Resources(skillsets)
4. historization(traceability)

Hope there is something useful to you in there...

Hi wjw,

Thanks a lot for your suggestions. They are very helpful. I would try to pick some inputs from your reply and incorporate in our use case.

Glad to know you found something useful there asham.

I enjoy thinking about and working with process flow and find questions like yours inspiring all sorts of other questions, which is what makes them challenging and interesting, particularly when Perl is involved.

Do feel free to use what ever was useful to you in your project and best of luck with it!

---

...the majority is always wrong, and always the last to know about it...
Insanity: Doing the same thing over and over again and expecting different results.