This week, FMI shipped FileMaker Pro 10 and FileMaker server 10. Among the new features, the biggest one affecting the developer's life is arguably the triggering capability.
This feature allows a script to be triggered flexibly upon many different actions. These include entering a field, typing a character, exiting the field, committing the record, entering a layout, exiting a layout, changing modes, and more. It has been possible to use a plug-in to trigger many of these functions in the past, but not all of them. Also, there are some things that a trigger plug-in could do that can't be done by FileMaker 10 natively. Mostly, these are triggers from a calculation or function.
In my opinion, this set of features in FileMaker will power a whole round of features that will become commonly used. Also, we'll see the rise of a set of very simple scripts that do small triggered actions that we've always wished for. For example, when a record loads, a script could load up a set of tabs based on a field value in the record. These tab panels might be visible or invisible. If an invoice record was paid, this script could show a tab panel with only locked fields. If the user goes to another record by any means (using flip-book, search, GTRR, etc.) the script would run to show the right tab pane with locked or unlocked fields.
This just scratches the surface, and I think hundreds of examples like this will emerge. This will certainly be my first use of these features, and I'll stop using triggering plug-ins for all of these functions as soon as my clients upgrade to FMP10.
The reason that triggering is important is that other development environments have had these features for many years, so a rich set of interface behaviors has emerged. It will now be possible to follow these standards without undue effort in FileMaker, which is a great thing. Sure, we could lament that this should have been done years ago, but we have it now, and it makes me happy.
Another use that I expect will be sweet is capturing mode changes. If a user hits Command-U (Control-U on winblows) to switch to Preview mode, a script could trigger that opens a new window, moves that window down and to the right, turns on the Status Area, and pauses the script with a 'Continue' button. Then when the user clicks 'continue' it asks if they want to print or not, and runs the printing subscript. Many of us have written scripts like this, but it will be even better now that we can capture native FileMaker commands and direct the flow to our wishes.
Saturday, January 10, 2009
Friday, November 28, 2008
FMPug done for 2008
Thanks for all who attended and presented in Portland for our FMPug Developer Group.
We finished out the 2008 meetings with a general tech question and answer on November 18. It was a very successful year of meetings, with attendance in the 20-40 range for each meeting. We hope to continue this in 2009. Please drop me a line if you're interested in presenting at one of our meetings!
We finished out the 2008 meetings with a general tech question and answer on November 18. It was a very successful year of meetings, with attendance in the 20-40 range for each meeting. We hope to continue this in 2009. Please drop me a line if you're interested in presenting at one of our meetings!
Friday, August 29, 2008
FileMaker open source?
There are a couple topics here. One is FileMaker Pro vs. Open source, and the other is how to develop FileMaker solutions and release them as open source projects. For the first topic, you can listen to the related episode on my podcast with Matt Petrowsky, FileMaker Talk.
It's the latter that I'm thinking about: Releasing FileMaker solutions to the world, for free, creating a community around the product, and integrating code from the members of the community into the master.
First off, FileMaker doesn't lend itself to this as well as other platforms, since all the code, layouts, scripts, reports, etc, are all in one file. This makes it harder to be modular. That said though, this is really primarily a philosophy decision, and I think it comes down to this in many cases:
A commercial company owns the code, but take nearly all the direction from the customers. An open source project makes the code public, so the customers themselves must become programmers. Neither approach is perfect, and each will be successful in the right set of circumstances.
Mostly, I'm interested in vertical market FileMaker solutions, so let's consider what it would look like in a relatively small community, where there are maybe 1000 potential organizations that will use the software. The economics are very different for software that is used by a million people.
No programmer works for free, and all models for development must compensate the people who do the work. In the commercial model, it's the owner of the code that pays the programmers. People who buy the software only have to make feature requests to make future versions better. In the open source model, each company that wants to improve the system must pay their own people to gain expertise in that technology, and to develop code for their version, and hopefully submit that code to the master so other customers (their competitors?) may also benefit.
I think this is a bit less likely to happen for a vertical market. For open source to be successful here, a large organization probably needs to fund the initial development, and may need to continue funding development over time. In this model, it looks quite a bit like a commercial product.
Both commercial and open source get funding from support, maintenance, training, etc. In the open source world, this is possibly the only source of funding. For commercial software, it's a small source at first, and becomes the primary source of funds as the company grows and matures.
These are some of my thoughts on the subject. I'd love to hear your comments.
It's the latter that I'm thinking about: Releasing FileMaker solutions to the world, for free, creating a community around the product, and integrating code from the members of the community into the master.
First off, FileMaker doesn't lend itself to this as well as other platforms, since all the code, layouts, scripts, reports, etc, are all in one file. This makes it harder to be modular. That said though, this is really primarily a philosophy decision, and I think it comes down to this in many cases:
A commercial company owns the code, but take nearly all the direction from the customers. An open source project makes the code public, so the customers themselves must become programmers. Neither approach is perfect, and each will be successful in the right set of circumstances.
Mostly, I'm interested in vertical market FileMaker solutions, so let's consider what it would look like in a relatively small community, where there are maybe 1000 potential organizations that will use the software. The economics are very different for software that is used by a million people.
No programmer works for free, and all models for development must compensate the people who do the work. In the commercial model, it's the owner of the code that pays the programmers. People who buy the software only have to make feature requests to make future versions better. In the open source model, each company that wants to improve the system must pay their own people to gain expertise in that technology, and to develop code for their version, and hopefully submit that code to the master so other customers (their competitors?) may also benefit.
I think this is a bit less likely to happen for a vertical market. For open source to be successful here, a large organization probably needs to fund the initial development, and may need to continue funding development over time. In this model, it looks quite a bit like a commercial product.
Both commercial and open source get funding from support, maintenance, training, etc. In the open source world, this is possibly the only source of funding. For commercial software, it's a small source at first, and becomes the primary source of funds as the company grows and matures.
These are some of my thoughts on the subject. I'd love to hear your comments.
Wednesday, August 13, 2008
WebViewer Madness
We've had the WebViewer in FileMaker for a couple years now, but there are still some great uses for this being found. One of the main uses is the Data URL. This allows you to use HTML code without having to have an html file on disk. The source of data can be a field or a script variable.
You can read more about this by following the link to Geoff Coffee's blog entry on Six Fried Rice. I'll keep looking for more cool uses of this.
One of my favorites is to use the webviewer instead of a FileMaker calculation to show the current record number, and the current found count. This is great because it's context universal - you can copy and paste the object to any layout, any database, and it just works. In the end, it's a layout calculation, and is very easy to use.
As much as I love the WebViewer, one thing that's a bit of a pain is syncing up the font size with the FileMaker fonts, which look pretty much the same on Mac and Windows. This is not the case for web code. It varies quite a bit across different machines, so requires some work to make it look the same.
You can read more about this by following the link to Geoff Coffee's blog entry on Six Fried Rice. I'll keep looking for more cool uses of this.
One of my favorites is to use the webviewer instead of a FileMaker calculation to show the current record number, and the current found count. This is great because it's context universal - you can copy and paste the object to any layout, any database, and it just works. In the end, it's a layout calculation, and is very easy to use.
As much as I love the WebViewer, one thing that's a bit of a pain is syncing up the font size with the FileMaker fonts, which look pretty much the same on Mac and Windows. This is not the case for web code. It varies quite a bit across different machines, so requires some work to make it look the same.
Wednesday, July 30, 2008
DevCon is Done
Well, DevCon 2008 is over with now, and it was great!
I'm hard at work developing a new product, called FM SearchKit, which will take off from the work I did for the 'Extending and Optimizing FileMaker Search' session I presented. I'd love some feedback on this. What do you want to see in a bolt-on search product?
I'm hard at work developing a new product, called FM SearchKit, which will take off from the work I did for the 'Extending and Optimizing FileMaker Search' session I presented. I'd love some feedback on this. What do you want to see in a bolt-on search product?
Friday, July 04, 2008
DevCon Prep
Getting all things ready for DevCon this year. Putting the finishing touches on my two sessions: Extending and Optimizing FileMaker Search, and the Separation Model. It's gonna be fun in the [hot] sun!
Thursday, March 17, 2005
Eric Clapton & Robert Johnson
Listening to Clapton's recordings of a collection of old Robert Johnson tunes today. So many things I love about this record, and after at least 20 listenings. My favorite track is 'Hot Tamales and Red Hots' Though it doesn't quite translate (I don't think he was talking about candy at the movie theater), it's just such a great jumping song.
Also, the recording is so clean and clear! Exactly the opposite if the originals, but that was 1920's technology after all - and it was one guy, one guitar, and probably only a couple takes per song.
Also, the recording is so clean and clear! Exactly the opposite if the originals, but that was 1920's technology after all - and it was one guy, one guitar, and probably only a couple takes per song.
Monday, February 21, 2005
Blues Music
What a great tradition is Blues Music. Like so many things, easy to start but hard to master.
Subscribe to:
Posts (Atom)
