Provide simple way to deploy multi-file solutions as document packages. Simplify the entrance/launch of a solution to the end users on both the desktop and iOS, by providing a single entity. At the same time, retain current benefits and developer flexibility while use multiple files to support the widely used separation model or multi-tiered FileMaker development.
This idea helps to solve
- A solution with 2+ files where the user is not sure which file they should double click on.
- Two releases of a solution Blitzen 1 and Blitzen 2, namespace problems where both contain internal file names like "Blitzen Storage" or "Sync Pro Plus". Specifically this makes it easier to drop in 3rd party solution modules.
- A crowded iOS document picker
- A plist/alias/soft-link would designate one actual fmp12 file, to be opened when the package is double clicked. All other files would be opened on demand, following the current model for multi-file solutions.
- Much of the motivation comes from FM Go. Desktop enterprise solutions are often hosted where we can selectively hide solution files to help guide users to the proper file to open. As many FM Go solutions need to work offline, we don't have anything equivalent.
- Windows support .... dunno sorry.... I'm not a fan of a .zip bundle because of headaches to replace a component.
- Yes, there is a little similarity to a run time solution, but really we are talking about documents here.
- File paths and references could be tricky. If there are two packages, as above, with each having UI.fmp12 and DATA.fmp12, then the reference file:DATA.fmp12 in the UI file needs to reliably bind to the adjacent file. Pretty sure this already works.
- Developers need to be able to easily detect the package mode. Might I suggest Get ( FileName ) should be amended to return "Biltzen 1/DATA" or else a new Get ( PackageName ).
- I see little need for packages on FM Server. I actually do not want to loose the ability to backup data files separately. Maybe the Upload to FileMaker Server... function automatically un-bundles a package, creating a new server folder and placing all the files in it.
- Maybe there is a clean way to include plug-in's inside a Package (at least on the desktop). Additional ideas needed for this topic.
- A Close Package step could provide a clean middle ground between Close File and Exit Application
- fmp:// url scheme could be enhanced address a package via it's main file. Even better, optionally address a file inside package.
Credit to tikidewey who got me thinking about this problem today with his Creating Folders in FileMaker Go idea. I think this idea could use some additional polishing, specifically on the Windows side.