This is the beginning of a new, open source project to create a lightweight wrapper for FileMaker Custom Web Publishing designed for use in JavaScript applications.

Background: DayBack

The release of DayBack for FileMaker last month has started a very exciting time for us here at SeedCode! Bringing the Calendar to a new code base and seeing it successfully deployed in the real world has been nothing short of thrilling. We’ve recently added mobile support and are looking forward to the future enhancements of DayBack for Pro and Go.

However, now that we have this great JavaScript code base, it’s time to get going on DayBack for the browser, and starting with FileMaker Server as our first data source is the logical next step.

Assumptions

One of the goals for DayBack is to do as much of the data work as we can in JavaScript. This is based on two big assumptions, and seeing how these bare out will be an interesting part of this project:

  1. FileMaker Server is a powerful tool, and it can do a lot. However, this ability to multi-task tends to lead to deployments where it’s simply trying to do too much. On the web publishing side things like portals on target layouts, server side scripting, huge data sets, etc. often put a considerable load on the server. Can we architect DayBack to do this kind of work in the browser and therefore put a lighter load on our FileMaker Server?
  2. Supporting server side processes requires a different level and type of support than client side ones.  This is not just the case for FileMaker Server, but any server based application.  Supporting the server often requires working on a specific machine with specific issues that extend well beyond your app, web servers, permissions, program versions, etc. can all affect how things run.  By minimizing our server side footprint we hope to minimize the need for this kind of support.

fmxj.js

With these assumption in mind we’ve built a preliminary JavaScript library for building and posting queries to FileMaker Server and converting the results to JavaScript objects in a JSON format.  We have some working demos here.  We’ve also decided to make this part of the project open source (MIT License), so you can download (or fork) the library and demos from GitHub for free!

fmxj.js - working examples

fmxj.js – working examples

Here is what fmxj lets you accomplish:

    • Build complex queries and perform HTTP POSTs to your FileMaker Server.
    • Return FileMaker parent and child records as JavaScript Objects/JSON.
    • Create, edit and delete FileMaker records with JavaScript objects.
    • Filter and sort Javascript objects locally with complex criteria.
    • Query strings are created from JavaScript Objects and then sent as an HTTP POST to FileMaker’s XML Web Publishing Engine. An XML FMPXMLRESULT is returned and converted into JavaScript Objects/JSON by fmxj.
    • HTTP POSTS can be done directly to the FileMaker Server’s XML WPE or a simple PHP relay can be used to get around cross-domain issues and provide more authentication options.

As always, we love to take any opportunity we have to share our code, and I’m personally looking forward to keeping you posted on our progress.

Cheers!


Tagged with →  

12 Responses to A JavaScript Approach to FileMaker Custom Web Publishing

  1. Brian Schick says:

    Jason, this is just… brilliant. The fmxj.js library looks powerful and really well thought out in JS terms. Kudos even more to you guys for choosing to release this to our community. Personally, I see this as a game changer: this comes at a perfect time, as we increasingly use JavaScript to do more and more “real” stuff with our FileMaker solutions. Thanks so much for this — and for all the work that obviously went into this. You guys rock!

  2. steve ssh says:

    Thank you for sharing your work. I believe that a library such as fmxj.js, combined with a client-side library such as AngularJS will be a powerful combination, and could be one of the best future methodologies for building CWP-type sites.

    Another advantage that I see is that it takes a step closer to writing chunks of UI code which can be shared between Pro (Desktop), Go, and a browser. I believe that, with the passing of time, more and more efficient techniques for writing this sort of UI code will be discovered and shared, and thus it will become easier and easier to write this type of UI code. I would even go as far as saying that this combination can open the door to deployment on non-iOS mobile devices in a native (albeit hybrid) app form.

    Thank you again for sharing and getting the ball rolling in this direction. As is evident from my comments above, I believe that it has much potential.

    -steve

    • Jason Young says:

      Thanks Steve!
      Sam Barnum from 360Works has an Angular library for FileMaker on Git Hub that I’ve been meaning to get into., so you might want to check that out as well. We’ve also heard some rumblings about some node.js adaptations which could be very exciting…stay tuned!

    • seedcode says:

      “a step closer to writing chunks of UI code which can be shared between Pro (Desktop), Go, and a browser” indeed. Thanks for your support, Steve!

  3. John Renfrew says:

    I’ll have some of whatever is in your water… It’s obviously making you super switched on. Love how simple this appears to be to implement, masking the obvious power that it brings into easy reach.
    And without any complex installs or workrounds.
    Top marks and kudos to all.
    Now all I need is a project that requires me to learn how to best use this.

  4. Brian Schick says:

    Jason, still loving this, but (gasp!) thinking over wider implications a bit more. So… a couple of new questions:

    – Have you explored how this performs at scale? I’m assuming performance will basically be gated by the XML API. Does that sound right to you?

    – Do you envision using fmxj.js on public web pages (with the scale & load issues that could bring), or do you see this as being targeted to Web Viewers (and perhaps browsers limited to more of a typical FileMaker workgroup-sized scale)?

    • Jason Young says:

      Hi Brian,
      Right, the XML Gateway is still the only way in. (PHP API is just an XML wrapper too). We’re finding that using our PHP relay is probably going to be the most practical deployment, but that too, just does a cURL to the XML Gateway.
      Our purpose is definitely the latter, in that DayBack will have subscribers that will connect to their known FileMaker server(s) as one of their potential data sources, and these would be people in that FM workgroup already.
      For public sites, I remain skeptical, but there are public sites out there, and I think the key to them staying up is keeping their server footprint light. No scripts, no portals, etc., and that’s what we’re going for here.
      I also think CWP performance is getting some residual benefits from WD, and I think we’ll continue to see that.
      Cheers!
      -Jason

  5. Bob Rens says:

    Jason —

    Great work! Thinking beyond the curent project… any chance this will evolve into a newer, better way to automate migrating FM native screens and functionality into a web browser? (Yes, sounds like a more robust scalable version of IWP!?!) And, better yet… thinking Mobile First… dynamically reconfigure for desktop, mobile and smart phone applications (i.e., Android and iOS)? Just a thought!

    Bob

    • Jason Young says:

      Hi Bob,
      Thanks for the post and kind words!
      That’s not our plan for now. The idea here is to just get FileMaker data in a light weight way and integrate that with our JavaScript calendar DayBack.
      In fact, we’re almost going the other way, in that we’re bringing more JavaScript into FileMaker via the web viewer. As Steve SSH mentions above, bringing JavaScript into FM Pro and Go and running in it in the Web Viewer may be a better approach to getting parity between the browser and Pro/Go than going the other way with IWP or WebDirect. Indeed, we’re seeing more and more WebViewer based solutions in both FileMaker custom and product solutions, so it will be interesting to see how this plays out as WD gets faster vs. FM devs getting more comfortable with JavaScript.
      Let me know if that makes sense or if you’ve got any other questions.
      Cheers!

Leave a Reply

Your email address will not be published. Required fields are marked *

Share →
DOWNLOAD
DayBack Calendar
Download DayBack and we'll send you a couple short emails with tips on how to modify it and use some of the coolest features.
Thank you! Please download: DayBack Calendar
Need More?
SeedCode tips & example files in your inbox
Need More?
SeedCode tips & example files in your inbox
Want More?
Be the first to see articles and tips like these
DOWNLOAD
TimeZync
Download TimeZync and we'll send you a couple short emails with tips syncing your FileMaker Go files.
Thank you! Please download: TimeZync
Want More?
Be the first to see articles and tips like these