in reply to Easy Grade Pro file parsing

Looking at the web site for this product, I found some relevant documentation, which included this (on a page under "Porting" about exporting the data):
• Export XML Gradebook. This format allows you to export virtually all student data from one or more classes in an XML format...

I didn't see any mention of XML on the page about importing data, but maybe that's not an issue for you (or maybe there are fairly easy ways to work around this).

In any case, I'd highly recommend XML as the way to go if you want to use perl on such data. Perl has an assortment of very good modules for doing useful things with XML, and you just won't need to worry very much that you might do the wrong thing with the data. (Well, it's always easy to make mistakes, but they're much easier to spot and fix when the input is XML, compared to some obscure application-specific file format.)

Who knows what sort of weird sh*t they might be doing with their proprietary file structure? (managing fonts, colors, user preferences, and all manner of other stuff that is probably irrelevant for what you want to do). Why bother with all that? (And if, like most designers of app-specific file formats, they've opted to mix ASCII and binary data, I wouldn't want to go there, if I were you.)

Replies are listed 'Best First'.
Re^2: Easy Grade Pro file parsing
by ruzam (Curate) on Sep 21, 2006 at 04:21 UTC
    Yes, found the XML export information. The key part of that description being 'export virtually all', which carefully dances around the fact that it doesn't export 'all'. I find Easy Grade Pro has a good number of configurable export options, all of which seem to leave one thing or another out (that or I'm just getting paranoid about the application).

    I'm hoping to bypass the EGP export all together and parse the raw .egp file directly (and yes it includes all manner of binary data). Wouldn't bother messing with it, if there wasn't a need :)
[reply]
      I find Easy Grade Pro has a good number of configurable export options, all of which seem to leave one thing or another out

      So the next question would be: Are there definitely certain things that are in the "native" file/app that you would like to see exported, but are never made available by any of the available export options?

      If the answer to that is "yes", it might be worthwhile pointing this out to their customer support people -- maybe they know something you didn't find, or maybe they would consider adding it.

      If you asked them for information about the "native" file format so you could parse it out for yourself with Perl, either they would provide that information, or else (more likely) they'd point to a clause in their EULA that specifically prohibits you from having that information or trying to figure it out on your own -- this tends to be the norm for commercially-developed software, and might have something to do with why no one has posted a CPAN module for this package yet.

      So unless their customer support is really supportive, your only hope is that everything you need could be exported, even if it means creating two or more distinct export files (XML and "custom template flunky3" and ...), then using perl to integrate those. Yuck.

[reply]
        Thanks. You've pretty much summed it up. I don't really have the time to reverse engineer the EGP format from scratch (much as I'd like to). But I feel it would be a good investment in time to build on someone else's work.

        It remains to be seen how much time will get sucked up explaining how to do the export dance to non-techi EGP users (they don't understand why they can't just import their .egp files into the application directly). In the end that could tip the balance.
[reply]

In Section Seekers of Perl Wisdom