Jump to content

Jason Lane

Members
  • Content Count

    26
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Jason Lane

  • Rank
    member
  1. Yup, my idea would only work with pages that use the GET method. Otherwise, iMacros sounds like it might work. Maybe some other plugins might server the purpose, too. Some to look at: http://filemaker-plugins.com/features/network/
  2. If you don't mind needing to use a plug-in, a better option might be one such as 360 Works' Scriptmaster, which can do both GET and POST. I hadn't tried it before, but I just tried it. It's free, and seems to work well. www.360works.com/scriptmaster/
  3. A server-side XSLT can have a FM username/pw hard-coded into it, so that when it executes, it can push records directly into the FM server. You could also do this with a PHP script (my preference since I know PHP better than XSL) using one of the available APIs.
  4. You can do all of this with FM, and FM has the Instant Web Publishing (IWP) feature that makes it relatively easy to put the DB online. However, IWP is not a highly optimized web serving solution, such as what you might get with a good PHP/MySQL implementation. FM's strength is in allowing you to develop a solution quickly and easily. For more complex and large-scale web applications, there are probably better options. I don't know anything about Flex, so I can't comment on that.
  5. Try putting a Web Viewer object on a layout. Specify a blank URL. Use the 'Object Info' panel to assign a name to this Web Viewer. Then write a FM script that uses 'Set Web Viewer [Go to url...]' and specify the URL (including the necessary key/value pairs). When you execute the FM script, it will send your data via GET to the script you posted, which will in turn (I guess) send a query via POST to the Canada Post system. You could get the reply by looking at the resulting content in the Web Viewer. Use the function GetLayoutAttribute to get the 'content' attribute of the Web Viewer
  6. Using PHP is certainly do-able and probably the best way, especially if you are already familiar with it. Sounds like you're already on the right track. I believe there's no problem sending the whole XML content as a single value. Then you could insert the XML into a field in your FM DB temporarily, until an internal FM script parses the XML and adds/updates records accordingly. Or, you could parse the XML in your PHP script, then construct the appropriate FM query. Alternatively, you could have the sending DB POST the data as separate key/value pairs (eg. layoutName, fieldNa
  7. Sorry, I replied without really thinking about the original poster's specific requirements... To pre-populate a form IN the browser, I can think of a way to do it, but it relies on a few assumptions and knowing a few things about the form/page you are trying to fill out. Firstly, instead of a Web Viewer, you can just use the Open URL script step to open the URL in your default web browser. Now, depending on the form you are trying to populate, you might be able to pre-populate it through the URL. For example, by taking a quick look at the source code of google.com I was able to fig
  8. I haven't tried doing this myself, so I could be totally wrong here... Couldn't you basically accomplish the same thing by setting the URL of a Web Viewer object on the FM layout? Something like Set Web Viewer [Action: Go to url...] and specify the same URL you would use in the cURL command? Eg. http://some.site.com/process.php?name=john&title=CEO Of course, the URL can be a calculated expression.
  9. It sounds to me like you are talking about Database Normalization. If you're not already familiar with the term/concept, there's plenty of information available online. If you are familiar with it, but have a more specific concern, please elaborate. BTW, I don't understand how creating separate tables for each 'section' is going to reduce your overall number of tables. I'm not saying it's the wrong thing to do, I just don't understand how that would lead to fewer tables. I might be missing something. Perhaps if you explained your existing structure, it might be more clear.
  10. I suppose it is a safe assumption, and a clever idea. So simple, yet I'd never thought of doing it that way. (Learn something everyday). Although I can think of situations that could break this, I think all of those situations should not be allowed to happen in a properly controlled and designed system, anyway.
  11. Effectively sorting by creation order? But you wouldn't assume that the last record necessarily has the highest pk, would you? I mean, it might be a safe assumption in a lot of (probably most) cases, but it's not a generic assumption I would apply across the board. Would you? Imported records would throw off the reliability of this method, wouldn't they?
  12. Yeah, that's pretty much the standard scripting routine I use for updates in my current solutions. But it's not so easy to make this 'generic.' You need to sort the records, and I don't know of a way to do something like "Sort by field ($pkField)", which means you need to hard code the sort steps for every table. I actually use a couple of CFs to determine the largest number without needing to sort, and then with the help of consistently named pk fields, I can just about make a generic loop that will set the next serial values for all tables in the db. Still... I like the idea of not hav
  13. Essentially, yes, and I initially thought that simply using a unique prefix & serial would work perfectly well when syncing distributed dbs. It was only when reading something in the SyncDek documentation that I came across a brief mention of a complication that can arise. When you come to update the db to a new version, presumably you would take a copy of the central db (making sure all data has been synced), import the data into your new version, then duplicate that, set the node-specific details in each copy, and then distribute the copies to the nodes. However, each node would need
  14. Yup, that's really the bones of it. Whether to use a nodeID or the MAC is almost an arbitrary decision (since the MAC identifies a node), though I can apply the MAC-based key form to all other solutions, not just those that are distributed nodes. There's also the off-chance that a nodeID gets set incorrectly (or mistakenly), causing records to be mis-identified in the central db. But this needs to be checked and properly handled by the program, regardless of the key system being used, so this shouldn't really be a factor in the decision.
  15. Point taken. And I guess, along the lines of what you said in the other post, the definition of 'negligible risk' is subjective. The obscurity of FM's random function is a little bit of a worry, even though it seems to work properly now. Well, I came to read about UUIDs as I'm working on a system that needs to be distributed and synced. And I will probably have to work on a few more systems like this in the future. For these particular cases, I'm already 99.9% convinced that I want to use UUIDs (as opposed to concatenating nodeIDs etc). But I also see merit in using it
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.