Posts

I’ve written some about Charting, and I’ve written about JSON. I realized I like working with these tools. It recently dawned on me, thanks to a conversation with Todd, that I could combine the two together into “FileMaker JSON Charting”.

So, I laid in the floor of my loft while the dogs happily chewed on bones or toys and worked through it. I tried to think of how JSON could work with a chart.

It took a bit, but I started with the idea that a chart needs a list of values for the x- and y-axis. And a chart needs its two lists to match up line by line. Read the previous posts for more detail.

I realized JSON is the PERFECT structure to keep the lists intact. I can create an array of JSON objects with the attributes:  “month”, and “sales”.

{
"lineChart" :[
{
"month" : "January",
"sales" : 50
},
{
"month" : "February",
"sales" : 3
},
{
"month" : "March",
"sales" : 0
},
…
]}

If I could somehow pull the values out of each item in the array, I could easily create a list and put it in the correct axis. It turns, out we have a custom function that will help with this:

JSON.GetValuesAtPath(array, path). found in our JSONAdditions.fmp12 file.

This function “returns a list containing only the values at that path”.

So I could do:

Let (
_array = JSONGetElement ( zSystem::JSON ; ".lineChart" );

JSON.GetValuesAtPath( _array ; "sales")
)

and get “50¶3¶0” in return.

Look. It’s a list. It is easily stuffed into the y-axis. For the x-axis  I can use the same calculation as above, but take out “sales” and put in “month”. Easy easy easy.

Expansion

It occurred to me during the JSON object creation process that I could add another attribute and use the new attribute in another chart:

{
"lineChart" :[
{
"dollars" : 415,
"month" : "January",
"sales" : 50
},
{
"dollars" : 22.8,
"month" : "February",
"sales" : 3
},
{
"dollars" : 0,
"month" : "March",
"sales" : 0
},
…
]}

So chart 1 works with month and sales attributes. And Chart 2 works with “month” and “dollars” attributes. Two charts for the price of one JSON object, AND they stay in sync.

Two charts for the price of one JSON object

Two charts for the price of one JSON object

That’s very cool. In fact, as I drifted off to sleep, I remembered there are JavaScript libraries that do this same thing. They are designed to pull from different attributes of the same JSON object.

So my main task became gathering the data from the fields into the array and, as you see above, placing it in a field.

Generating the Data

I won’t go into a lot of detail about the method I used to generate the data. You can see it in the download. Here are the highlights:

  1. Find the records with the matching year and product.
  2. Gather the JSON data in some format. I’m looping through the records and creating objects which will go into an array, but there are other ways.

    Collecting data into an array

    Collecting data into an array

  3. Update the existing JSON object in the correct path. In my case: “.lineChart”.

Ever Expanding

I can expand the idea of FileMaker JSON Charting. A JSON object is useful for holding the data necessary to fill out a chart. A JSON object can have many parts to it. The line and column chart above run off of the “lineChart” nested array. I realized I could have another nested array for another chart: “pieChart”. In fact, it occurred to me one JSON object could run an entire dashboard, including a virtual list! Woo!

An entire dashboard powered by one JSON object. Complete FileMaker JSON Charting

An entire dashboard powered by one JSON object.

This dashboard runs off of one JSON object. The JSON object contains a nested array for “pieChart”, and one for “lineChart”.

The JSON object

The JSON object

The Year field at top left determines  the data to be shown, so the JSON object is re-rendered each time. And the additional choices at top further refine the data displayed.

Updating the Data

My scripting gathers the data and then overwrites what’s already in the JSON object with new data. So if a user chooses 2016 and “Peaches” whatever is in the “lineChart” key will be replaced with new data. This is useful. I don’t wipe out other data that is powering other charts.

FileMaker JSON Charting Further Considerations

I woke up in the morning and, as often happens, an idea popped into my head. I could set up my JSON object to collect data for the entire range of years and products and refine the calculation for each axis in the charts to drill down to the path for the year and the product the user chose above. No re-capturing of the data.

But why would I do all this? I could very easily create many table occurrences and filters and such to display the same data. I think that answers my question. These charts are completely context-free. the JSON is stored in a field (or could be in a global variable) and available no matter where the objects happen to be.

Again, JavaScript libraries do this: ‘reduce’ and filter from a huge JSON object to what is needed for a particular chart.

I’m sure there’s some more that can be done here. I’ll continue to play with it and see what else I come up with, but if you’ve got any ideas, let me know in the comments below.

Download the Demo

I’ve only been around the FileMaker world since FileMaker 9, where I stumbled into it at the school where I was a teacher. So I’m relatively new, though have got a respectable number of versions under my belt. In that time, I’ve seen native FileMaker grow. It has evolved from a database tool to a platform upon which we can develop and access highly-complex custom apps.

Each release of FileMaker brings more features, more tools we have inside the application to develop our own custom apps. And we are grateful for it. We can now use JSON natively. We’ve been able to connect to SQL systems for many versions, and we have cool layout transitions for iOS. We have been able to create custom web pages with CWP technology. With native FileMaker, we can reach out to a web service and retrieve data. The list of native FileMaker possibilities has grown.

But there have been questions about what constitutes native FileMaker. I am guessing because the platform is much different than in FileMaker .fp3, .fp5, of .fp7 days, people worry that they have to work with stuff that’s not native FileMaker.

So let’s discuss what constitutes native FileMaker.

What is Native FileMaker?

Native FileMaker is simply what you can do with FileMaker that requires no additional install of other apps or tools. Additionally, native FileMaker is anything we can do inside of the platform using the tools, objects, functions, script steps, and schema to solve a use case from our client.

Native FileMaker, by the above definition, then includes the following:
  • Using the JSON syntax to collect data into an object
  • Using the web viewer to build a list view or complex chart using JavaScript
  • Connecting to a weather api to get the latest weather forecast
  • Using a virtual list of data from many different tables into one table
  • Creating a web page using Custom Web Publishing that shows data from a FileMaker custom app.
  • Creating a SQL query using ExecuteSQL which collects data from an unrelated table in our app.

And much, much more . . .

I have presented these to folks and have gotten back the challenge that these are not native FileMaker.  I respect the thoughts of those folks and so I spent some time thinking about how their thoughts differ than mine. And I think it is because there’s a concept of “Idiomatic FileMaker”.

Idiomatic FileMaker

Idiomatic FileMaker includes, it seems, that which we think of first when we think of FileMaker: Scripts, fields, schema, layouts, rectangles, text boxes, etc. That’s what we first learned about as we began our journey. This definition of FileMaker is all well and good but it severely limits our ability to do much with the application. Idiomatic FileMaker hasn’t changed a whole lot since FileMaker 7, and if we stay thinking of FileMaker in these terms, we risk being left behind in the custom-app development world.

Expanding Native FileMaker

But “native FileMaker” has changed. The engineers at the Wedge (the nickname given to FileMaker’s headquarters–a wedge-shaped building) have added so much more to the platform. There is almost no limit to what can be done. (I once pointed out we can’t do 3D drawings in FileMaker. I was corrected. ) And we are glad they have done so. We are glad we can now natively parse JSON with no plugin. It is awesome we can connect to web services and get back data and easily work with it. It is amazing that we can create a list of records using data from all over our custom app without having to build lots of relationships or calculated fields while de-normalizing data. Instead, we can create a virtual list which is native FileMaker, but may not be idiomatic.

Keep Moving Forward

We should take advantage of native FileMaker for our clients. We should leverage everything the platform has as our clients require it. Let’s say our client wants a list view that has columns that sort and a filtering mechanism and even expandable rows, we should seriously consider using a web viewer integration of a DataGrid. If our client wants to be able to send items up to box.com, we have to explore data APIs and Insert from URL. If the client wants to see the weather forecast in their app, we should turn to parsing JSON from a web service that FileMaker has reached out to for the latest information. With open arms, we should embrace the virtually-limitless capability rather than shunting much of it to the side.

The rest of the software development world has already embraced technologies that expand their app. We, as FileMaker developers, designing the best possible custom app for our clients or ourselves, should do the same. FileMaker is not a small-time system anymore (not sure it ever has been small-time). Let’s use native FileMaker to its fullest.

FileMaker Go solutions that are installed locally on the iPhone or iPad provide a better over-all user experience because they are faster than hosted solutions and can work even when you don’t have a good connection. Once you decide to go down this path, you are faced with two problems. First how do you exchange data with the hosted FileMaker Application? Second, how do you deploy new versions of your solution to your users in the field?  These turn out to be fairly complex problems. GoZync was designed to solve them!
Read more

I had a great time at the Southern Ontario FileMaker Association meeting.  The weather was really nice. I didn’t even need to break out my winter coat. I want to thank Dave Pong for setting it up, and for getting the word out. Thanks to every one who came.

Read more

After I got home I recorded my entire session from this year’s DevCon. Here it is along with all the files that I used in the session. Hope you enjoy. Read more

While John Sindelar and I were doing our West Coast FmPug tour we sat down with Matt Navarre to do a podcast. Actually we didn’t sit, we stood, but you get the idea.  We talked about the upcoming release of GoZync, and a bunch of other things, like the MacBook Air, Transactions and well … dirt.

Check it out

For years I have been using a recursive custom function to get a list of all the Selected Tab Panels on a layout.  This works quite well, but in my current project I wanted to get rid of all custom functions. I didn’t really want to use a looping script. I wanted a pure calculation that could do it.  This is what I came up with.

---------------------------------------------
Evaluate("List(¶"  &
Let(
[
left =  "Let([tab = "";
right = ""];Case(GetLayoutObjectAttribute ( tab ; "isFrontTabPanel" ) ; tab;""));";
tabs = Substitute(
  LayoutObjectNames ( Get( FileName ); Get( LayoutName ) );
  ["<¶";""];
  [">¶";""];
  [">";""]
)
];
left &

Substitute(
   tabs;
   "¶"; right & "¶" & left
) &
right
)
&"¶)"
)
---------------------------------------------

This seems to work pretty well.

Apologies, the download file has gone missing.

 

UPDATE:   I got re-tweeted by Sencha Inc. it blew out my bandwidth at screencast.com. That is totally cool!

I have been doing a lot of work with JavaScript lately. Specifically looking at how to build cross platform mobile web apps that connect to FileMaker.  There are some pretty cool libraries available out there that significantly reduce the works load. I had some time at LAX waiting to fly out to pause on error. So I whipped up this little demo using SeedCode Complete running on my FileMaker server in the Cloud and local <a href=”http://www.sencha.com/products/touch/”>Sencha Touch</a> Application.  Check it out.

One of the interesting things about this app is that it requires no server side code at all.  There is no PHP, no Groovy, no Java, no nothing, other than FileMaker running on the sever.  You can write server side code and that probably makes sense to do so in the long run for anything complex but it is not required. In this demo we are using javascript to connect directly to the XML gateway on FileMaker Server.

Perhaps the most interesting thing about this application is that it will work on any mobile device that has a webkit baked browser  So we are not limited to just iOS devices, like iPhones and iPads.  This will work in on WebOS, Android, Blackberries. Windows Mobile 7 support is around the corner.

And Perhaps I should mention that this is not limited to Mobile devices either.  SenchaTouch is based on on <a href=”http://www.sencha.com/products/extjs4-preview/”>ExtJS</a>, one of the most powerful libraries around for building rich web based applications.

Here is the movie.  Hope you enjoy!

Geist Interactive is proud to announce the release of proSign v1.0. proSignp makes it easy to add signature capture to any FileMaker Pro solution. Signatures can be captured using any touch pad or pen and tablet input device. No special hardware is required. It runs on both Mac and PC. It requires FileMaker Pro version 9 or greater.

Signatures are captured and stored as Base64 encoded data urls which makes them easy to display in web viewers or to embed into HTML email. You can also convert these into PNG files later for storage and display using the free GoSignCompanion plugin.

Geist Interactive founder, Todd Geist, said “proSign is a follow up to our proSign for FileMaker Go product. Many of our GoSign customers asked if we could come up with a version that worked on regular FileMaker Pro. proSign is the result.”

proSign is available by itself for $239 or bundled with GoSign for FileMaker go for $289.00. Existing GoSign customers are eligible to get proSign at a special price of $219.00 For more information on pricing and to try out demos, please visit the GoSign web page, http://www.geistinteractive.com/proSign.

Geist Interactive is a FileMaker consultancy known for its creative outside the box style and for its deep knowledge of the FileMaker environment. Todd Geist, Geist Interactive’s founder, has given presentations and training seminars at conferences and events all over the United States and the United Kingdom. Geist Interactive is located in Newbury Park, CA.

###

Todd Geist – Owner

805-419-9382

todd@geistinteractive.com

I am very excited to announce my first actual product for sale here at Geist Interactive.  GoSign – easy signature capture for FileMaker Go!  Using GoSign you can add signature capture to any FileMaker Go application in about ten minutes.

The core technique involves using a WebViewer to display a jquery based JavaScript/HTML5 application that lets someone scribble their signature directly on to an iPad or iPhone, just like they do in the Apple store’s now. Needless to say this involves a lot of moving parts.

GoSign Packages all the JavaScript, HTML, and FileMaker logic into some scripts and layout objects, that can easily be moved into your solution.  It requires no changes to schema other than the the field need to store the actual signature data. The integration points are few and well defined.

For more info pricing, and to download a demo, check out the GoSign webpage.

A special thanks goes out to Richard Carlton of Richard Carlton Consulting (RCC) for being customer number 1!