Week 4: Conversion to an XML-Interpreting Program

Mar 31, 2020

Hello all,

Last week, I planned to integrate XML into my program, and it worked! Let me give some background first, though. My previous GUI code worked, but the information about the tasks, succession, and layout was hardcoded into the program. This means that I wrote all of the directions in – python was not drawing data from another file or application. The goal was to get the program to take in an XML file as input data. An XML file is essentially a list of lists within lists, and it’s formatted similarly to notes taken in class. There is a main category, and within that category is data, along with more subcategories. Here is an example:

Here, under the main root category “books,” there are multiple books with different subcategories of data such as “title” and “publisher.” Just like this screenshot, I wanted to make an XML file that would outline tasks to run. 

 

Progress + Problems

After looking over my hardcoded program, I drafted the said XML file (preview this if you want any of what comes next to make sense). As you can see, under the main root category “tasks,” there are multiple tasks with different attributes such as “name” and “path.” These are just like the elements in the previous example, like “title” and “artist,” only more easily accessible (in my opinion). Going through what each attribute means/does: “Name” is the task name that appears on the GUI; “Path” is the directory where all of the action happens; “Batch” is the batch file that the task runs; “Pauseafter” identifies whether there is a User Pause after the given task; “Type” determines what the python script should do with the task; “id” gives the order in which the tasks will run. 

Making the XML file was the easy part, though. The hard part was designing a program that takes all three sides of the problem and puts them together: XML, Workflow, and GUI.

The key to this development was “for” loops. In these, the computer cycles through a list of things, whether that’s a list of names, numbers, etc. For instance, instead of manually designing each header and button for the GUI, I made a “for” loop that essentially cycles through each, generating its name and a button that presents directory links when pressed. 

One key obstacle that I found was designing the program to be as skeletal as possible – I didn’t want to code anything into the python script that wouldn’t always apply to the workflow I am running. A prime example of this was detecting where I would want the system to pause and wait for the user to press “continue.” The way I got around this was making multiple lists and indexes to represent things like where the pauses should be and the intervals through which the program should run before stopping. Those who have dealt with complicated data structures and loops know that it is not fun to keep track of the different variables and what they mean. 

So I put everything together, and it ended up just as good as the original. But I wanted to take it further and test the bounds of this new system. If the program takes an XML file as input, then anything I put on the XML file should appear on the screen, right? It shouldn’t matter what programs, program names, and directories I use if all the program is doing is interpreting a file with data on it. This turned out to be a success too. Playing around with the input, I was able to change all sorts of aspects of what appeared on the GUI. 

Here are some links you can use to visualize/experiment:

Click here to see a video of everything running.

Click here to see the code and here to see the XML file.

 

Experience + Next Steps

This week was one of my best so far because of the material progress that I made. I can’t lie, finally getting something to run cleanly after hours of troubleshooting is a feeling like no other. Next week, I plan to make the GUI a bit more appealing to the eye, looking more like how I originally envisioned the GUI. After this, I want to take what I have made and apply it to the real customer’s system in a test environment. Hopefully, everything works well from the start, but I anticipate errors stemming from the increased complexity of the new environment. 

Thanks for reading, and as always, feel free to leave any questions/concerns in the comment section!

 

2 Replies to “Week 4: Conversion to an XML-Interpreting Program”

  1. raulr says:

    I am glad to see all the progress you have made in your project. I was kinda exited for you to use Luigi (just for the amount of video game references I could have made – like how the interface was green!) Continue with the great job… and tell us how working from home has changed your they way you work on the project. Working from home means that your environment does not change for work, and sometimes that can be challenging.

    Keep up the good work!

    1. Thomas E. says:

      Yes, switching from Luigi was sad for many reasons, I guess including the lost opportunity for video game references. Working from home has been a pretty big switch for me… I will be sure to include details in my next post. Thanks for the feedback!

Leave a Reply

X