First, understand that I know next to nothing about Ruby (except peripherally). So take what I have to say in that context.
That said, your question 2 is basically faulty. Ruby is not supported by FileMaker at all. The clever folks who have developed the connection API for Ruby have done it on their own. Doesn't mean it's not good; doesn't mean it's not a viable alternative. But if you're worrying about support from FileMaker (as question 2 seems to indicate), then you're already on shaky ground. You'll have to get your support from the people who developed the connector, not from FileMaker.
Another example in this space is the FX PHP API. Most of what I've read about it was that it was faster and more efficient than the FileMaker-provided API. I have no idea if that's true; I never used it. But it wasn't supported by FileMaker, either. (I honestly don't know if it's still around or not; someone else with knowledge, please chime in.)
As far as which is better to learn - Ruby or PHP - I can't tell you. If, as you say, you predict a need to learn Ruby for future endeavors, then that might be a better way to go. PHP is widely supported, has a very robust user community, and is well-established. I presume these features are present in the Ruby community, as well. I remember hearing about a Ruby on Rails connection to FileMaker at DevCon some years back (2008, maybe?). But it's niche. Even more niche than PHP for FileMaker. That's something to consider.
If you come to this board looking for help with Ruby development for FileMaker, you probably won't find many people who have experience with it. If you go to a Ruby board looking for help, you probably won't find too many people who know how to spell "FileMaker". OTOH, you'll find plenty of people here with experience with the PHP API. So that should be a consideration, especially as a newbie.
I don't know how much that helps you. I've done a fair amount of PHP development with FileMaker back ends, so I can speak to that. I've not touched Ruby. Perhaps someone who has experience in that arena can assist you.
I'm a bit on the conservative side. I tend to lean towards features that are supported by FileMaker, and shy away from third party technologies. There are already so many variables in a computing environment that you can't control, and adding additional unknowns just adds risk. Others disagree. Where you fall in that continuum will tend to drive the choices you make.
Thank you Mike,
Your thoughts are really helpful.
I wasn't aware that Filemaker doesn't support Ruby officially
Filemaker work is going to be my main focus so maybe as you suggest looking at PHP may be better considering the support .
I wouldn't fret the official support. There are APIs out there for FM that cover Ruby (like you've discovered) but also .NET (fmdotnet.org - which I maintain), Python (PyMaker) and a few more. These are all open source so it is really easy to tweak it where needed. In the end they all use the underlying FMS XML API and that one is fully documented and supported. All that those APIs do is construct the proper URL that gets sent to FMS and parse the returning XML grammar.
But those APIs serve a powerful purpose: they allow Ruby programmers, or .NET programmers to work in their native / trusted / comfortable bubble without having to learn anything about FM whatsoever.
Love Wim's answer. I want to say this:
API = "application program interface, is a set of routines, protocols, and tools for building software applications".
Here's an answer when you search for 'FileMaker API':
With FMServer we have several ways to GET data for custom web publishing (CWP) that could be "API":
1. XML (queries through functions) that can be used by ANY application that can send and receive and process the XML.
2. PHP API (which makes XML queries!) and is a set of routines, protocols & tools working with specific grammars of the XML in FM and uses PHP
3. Fx.php (which makes XML queries!) and is a set of routines, protocols & tools working with the grammars of XML in FM and also uses PHP
3. Ruby (which I believe uses the XML)
4. .NET and/or ASP (which I believe uses the XML)
5. ODBC/JDBC, yes these still can be used for Custom Web Publishing with any application that can process. (Look, ma, no XML!) And yes PHP can even make SQL queries.
and there may be more methods, but the point is that there are really TWO ways to send/get data with Web Publishing. At one time AppleScript was a web publishing method, tho I have not seen any evidence of it lately. Your two choices: XML or xBDC. From there you choose the web application(s) and API(s) that can process the queries and results. Yes, it is entirely possible to mix web applications, APIs and even XML and SQL in one website, if you really want to!
Choose something with which you are comfortable. If you don't have experience, then choosing PHP may or may not be the best choice. It's likely that over and above the API, you will need to learn a lot more about your choice. And doing so opens such possibilites to expand over what you may get from the canned API anyway! But learn you must at some point.
Wim and Beverly have passed on some very good advice. (I'd completely forgotten about the intermediate XML layer; emotional trauma from doing direct XML web publishing years ago. They're much better with XML than I am, so that's to be expected.)
The only other thing I would add is the "mindset" of the API will matter. The FileMaker API attempts to mimic the "layout-centric" nature of FileMaker itself. Most of the methods make calls to the database against a layout. This will be familiar to you if you've worked in FileMaker, and will mean you'll need to be familiar with the database you're pulsing. This is a good thing if you're a FileMaker person. It's not so good if you come from a non-FileMaker background and are accustomed to querying against tables or views via SQL and connection strings, which most environments are. So if you're interested in "transplantable" skills, the FileMaker API may not necessarily be the right way to go (although it's not all that hard once you know, say, PHP, to make the leap; I've worked with PHP in a mySQL and SQL Server environment, too).
Thanks, Wim and Beverly for chiming in.
Thanks for the comment. Wim. You mentioned pyMaker a few times before. Do you have a link to the project? If I try to google it, I can only see the dev tool for Pygame.
Thank you all for the inputs this is really informative , I will keep these things in mind when I make my choice .
Thanks. It is also on pypi, of course - found it after you gave me the name.
I am taking a leap and have started learning learning ruby on rails . Hope to connect to the FM Server ...
Interesting to see the many ways to connect, yet no method is considered "best"
Some also prefer Lasso:
For one client, I even use FileMaker as a JDBC backend for Servoy
> I am taking a leap and have started learning learning ruby on rails
PHP will almost certainly be easier for you to learn than Ruby/Rails if you don't come from an OOP/MVC background. I've previously worked on a few RoR sites and they're a pain, just to get configured to the point of editing some HAML.
That being said, if you're looking to be a career developer, don't put all of your eggs in one basket. Python is a good partner language to PHP to pick up. You'll also need a good handle on HTML5 and CSS3 going forward in web development.
There are tons of free resources for learning PHP, such as codecademy.
+1 to learning HTML and CSS. Also, it's worth noting that, while PHP isn't really an object-oriented environment per se, you can structure your code in an object-oriented paradigm if you so desire. (The FileMaker API is an example.) Helpful if you want to move in that direction later.