Robert Klemme said:
So, people will write the functions using Ruby sytax in the future?
That's correct. One of the greatest advantages is that ruby is very good at
pinpointing errors. Our previous language was 'forgiving' in the awk/perl
tradition. Could be tough to debug.
This one apparently doesn't use any environmental data. (Btw, you might
want to add "^" and "$" to that function.)
You're right of cource. It was just a quick example of the level of expertise
needed to write such functions.
[ cut]
Aha, so the instance of your class at hand has instance variables and
predefined methods that some of the functions can use.
And it seems, you want to keep the config file syntax while changing the
sytax that the function definition interface (or file?) uses to Ruby. So
basically you parse the config file and generate a method that reflects
invocation sequence of the other methods. Something like that.
The configuration file is a xml file that also describes the layout of the
different tabs and subscreens. This is a client/server system with Windows
clients and a Linux server.
I guess, I got the broad picture. Now I'm just missing the connection to
the original problem.
Now it gets even more complicated: the old system had a special kind of field
for repeated groups of fields. Kind of a matrix. On screen there was room for
one row at a time, the first row item acted as the key. This field had a
name, say 'cassettes', and it was exposed to the end-functions as a two
dimensional array: cassette[row][col]. The titles were exposed as
cassette_cols[], and the keys as cassette_rows[]. This is what I tried to
do. An end-function can fill on or more rows (and maybe display one on the
screen).
With the above trick, the same exposure can be achieved in ruby.
Hope I haven't been to unclear: it's all about changing as little as possible
for the people who have to work with the new system.
Cheers,
Han Holl