Re: Filemaker and Database events
Re: Filemaker and Database events
- Subject: Re: Filemaker and Database events
- From: has <email@hidden>
- Date: Mon, 14 Jun 2010 22:34:56 +0100
Ed Stockly wrote:
> It starts with pipe delimited raw text file with thousands of records each with 15 to 18 fields. (It's a fixed fileformat that is used in a number of applications, that won't change)
>
> Each file lists everything on TV on 90 different channels for one day.
>
> Sometimes we work with one day's listings, sometimes one week's listings and sometimes with three week's of listings.
>
> The file format is fixed and not internally consistent. Movies and sports programs each have a different number of fields than the rest of the programs.
>
> Importing into FM from appleScript is a real pain because you have to convert to XML (which takes a long time) then save the xml file to a standing file that a filemaker script can recognize for import.
Converting pipe delimited text to XML would be nice and speedy using (e.g.) Python, which is included in the OS and has fast (if slightly quirky) XML APIs, regular expression support, and all the other bits and pieces you need for moderate-to-heavy text/XML munging. That'd be one option.
Another option: you can push big lumps of data directly into FMP as lists (or lists of lists), which should also be quick to generate using vanilla AppleScript. If I was pushing pipe-delimited text into FMP cells, that'd probably be the first route I'd look at.
> Importing the same data into DE takes about 1 minute, as opposed to 10 in FM.
>
> But, if I could import into DE, then read those files in FM, that would be cool. Then I only touch the raw files once, get the speed of DE working with inDesign and the UI goodies.
Depends what UI goodies you're after and who they're for. For example, these days a lot of our user-facing controls are web-based. We still use some desktop-based utilities, but that functionality is gradually migrating server-side and new projects are usually server-based from the get-go. If I was building a system similar to yours, and assuming no user interaction is required once the job is underway, I'd probably look at keeping all the data server-side in (say) MySQL and provide a web interface where users provide all their input needed. The server would then spit out a ready-to-use job specification in XML (or whatever) that can be fed directly into the client-side AppleScript. Or, if the budget can spring for InDesign Server, just stick everything on the server and sling out a finished file at the end. But that's a lot of what-ifs and so on, and assumes you've got a web server to play with and someone to code the webapp to run on it, and might or might not be the right solution depending on the detailed requirements.
Another thought: how vital is FMP to the system? If you won't be storing the data for any length of time (and it doesn't sound like you will), could you just stuff it directly into DE and provide a Studio/ASOC interface for working with it there?
HTH
has
--
Learn AppleScript, 3rd edition, Sanderson & Rosenthal:
http://apress.com/book/view/9781430223610
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden