Here’s an overview on how the sample file works:

• The layout asks you to enter a folder name and a location for the folder (either desktop or documents folder). If the location is the same every time, you can hard code the location in your script.
• The script confirms that none of these values are empty.
• The subfolder name is calculated based on the date and time. This ensures that no two subfolders will have the same name, which would cause an error.
• Check if we are on Windows or Mac.
  • If we are Windows, we run a Send Event script step that makes the directory specified.
  • If we are on Mac, perform applescript to create the main folder, and then perform applescript again to create the subfolder.
• Let the user know if there was an error or if everything was successful.

You can download the demo file here: CreateFolders.fmp12

The post Creating OS Folders and Subfolders with FileMaker appeared first on Soliant Consulting.

Note: Unfortunately AppleScript is only available on Macs, so this solution will not work on Windows machines.

In the sample file below, you will see a demonstration on how to combine 2 PDFs using AppleScript. You will create a shell script that leverages Automator’s combine PDF function, and then run that shell script using AppleScript.

Download CombingingPDFsWithApplescript.fmp12

The post Combine Existing PDFs in FileMaker Using AppleScript appeared first on Soliant Consulting.

It’s not uncommon to come across list layouts in inherited solutions – files which you are maintaining but were originally developed by someone else – which use unstored calcs and summary fields. If the list view is loading slowly, one of the first step in diagnosing the performance issue is to remove these fields to see what impact that has.

But to do this, we need to determine which fields on the slow layout are unstored calcs or summary fields. When a layout which you didn’t create in the first place has dozens and dozens of fields, and the field naming convention doesn’t readily reveal the type of field, then this can be a somewhat tedious task.

Creating a Database Design Report (DDR) will give us this information, but it takes a little bit of time to do, so is there a quicker way?

Yes, there is (with a caveat, of course) – we can use the two FileMaker design functions FieldNames and FieldType to accomplish this.

The caveat is that if the unstored calc or summary field exists on a layout as a merged field, it will not be detected.

The accompanying demo file, which is based on the FileMaker Assets starter solution, has two approaches built-in:

The first approach uses a script that scans the entire file to create a sort of mini-DDR that lists all layouts containing unstored calc and summary fields. The result is reported in a global variable which you can access using the Data Viewer.

The second approach uses a custom function, which I named “SlowFields”, to find unstored calc and summary fields on the current layout only. Here is an example of what this custom function returns when evaluated on the Asset Details layout:

The script and the custom function are each standalone and completely portable (and they are independent of each other), making them easy to copy into other solution files.

You can use either approach depending on your preference and the situation you’re working with.

The post Quickly Find Unstored Calcs and Summary Fields appeared first on Soliant Consulting.

How to build your own logging system.

A fairly common activity in Salesforce is to create managed packages. There are a few reasons for this. First, it makes it easy to deploy updates to multiple clients. Second, it allows you to protect your intellectual property by preventing your code from being seen or modified. Finally, it is a requirement for listing your package on the AppExchange.

You can create these packages very easily or you can go through a full security review from Salesforce. This review process can be very difficult and there is a lot involved in it, which include checking code for vulnerabilities (which is good to do anyways), making sure sensitive data is hidden from the correct people, making sure all code is bulkified, and ensuring that any external systems that connect with the Salesforce instance are also protected from vulnerabilities. In addition to this, there is a hefty annual fee to post your product on the AppExchange. These things can be daunting and may make you decide that you are better off not doing it. In the case that you don’t complete a security review, it will become very difficult to debug in client orgs. You cannot obtain access to debug logs of managed packages without the security review. This allows the client org to allow you to access the logs in the system. I devised a way in order to add some custom logging into your package that can be turned off and on without all of this extra headway.

Your first step is creating a new object to store these logs in. The simplest setup would be to make an auto numbered name and a long test text area for your logging message. (Keep in mind how long you make this restriction because your code can’t can not exceed it.

Figure 1 – Error Log Object

Figure 2 – Error Log Fields

You will also need a way to denote whether your logging is off enabled or on disabled because you don’t want to be creating lots of records that you will likely never look at. You really only want logging on when you are actually looking for themlogsthem. You should create a new List custom setting with a sufficient name such as ‘ErrorLogControl’. It just needs to contain a single field ‘IsLogging’ in order to denote whether logs are enabled or disabled.

Figure 3 – New List custom setting

The class starts out like any other class except for one important change. This class should start off as pretty much any standard class except for one change. You want to specify It is important to define the class with the ‘without sharing‘ keywords so that no matter what User you are logged in as, the logs still get created.

public without sharing class ErrorLogControl
{

You only want to check if logging is on once so that you don’t hit governor limits and is just generally efficient. This ensures that you don’t do that. Once you check for logging, the variable gets stored for the next check. If it’s empty, then the code knows that it needs to populate it.

private static boolean isLogsOn
{
	private get
	{
		if (isLogsOn == null)
		{
			List<ErrorLogControl__c> control = ErrorLogControl__c.getAll().values();
			//If the custom setting is not here, assume logs should be off
			if (control.isEmpty())
				isLogsOn = false;
			else
				isLogsOn = control[0].IsLogging__c;
		}
		return isLogsOn;
	}
	private set;
}

Code should not be allowed to access the logs any way on this class besides how the class dictates. Declaring this as ‘private static’ allows nothing but only this class to touch it. That way you can’t have special circumstances that another developer wants to bake into the code, which can get confusing fast. This keeps everything controlled.

//Somewhere to store this list of logs that is hidden
private static List<Error_Log__c> eLogs
{
	private get
	{
		if (eLogs == null)
		{
			eLogs = new List<Error_Log__c>();
		}
		return eLogs;
	}
	private set;
}

This controls the actual creation of the logs. The code checks to see if you have logging on, and if so tells it go ahead and create and, if so, creates the log.

public static void addLog(String message)
{
	if (isLogsOn)
	{
		forceLog(message);
	}
}

The other addLog method uses this the forceLog method to actually create the logs. This is where you can add some flexibility into your own code. Say for instance you wanted to track something special, you can add it in here. The reason I have a second method for doing this, is in case you want to do some logging regardless if you have logging turned on or not. This is useful when an error in the code happens and you want to be able to see the issue regardless if they the user had the logs on. That way you don’t have to turn on logs and replicate the caught error. In this instance here, I added a ‘Created_Time__c’ custom field so that I can sort by the time of execution instead of the CreatedDate (which only tracks date) or the CreatedBy (which will sort by User then the CreatedDate and then the Timecreatedtime).

public static void forceLog(String message)
{
	eLogs.add(new Error_Log__c(Created_Time__c = DateTime.now(), Error_Messages__c = message));
}

This is one of the harder pain points of this setup. The logs need be added to the database at the end of whatever execution of code is going on. This is one of the harder pain points of this setup. Because of that, you might actually have to commit the logs multiple times. For example, you have work going on in a VF page, that will commit logs at the end of an action, but you also have the commitLogs() at the end of a trigger in case they change data through a standard layout. Because of this case, this method needs to make sure it clears the current set of logs each commit so that it isn’t trying to insert the same log twice causing an error and then other logs to fail on insertion. The rest could be handled however you desire. Originally, I only had the check for empty an empty list and insertion of the records into the database with the clearing of the list afterwards. That is the bare minimum you should have. I added some extra result parsing and exception handling though. These could let me add another log basically to say ‘hey these other logs did not insert, something is wrong’.

public static void commitLogs()
{
	if (!eLogs.isEmpty())
	{
		try
		{
			List<Database.SaveResult> results = Database.insert(eLogs, false);
			for (Database.SaveResult res: results)
			{
				if (!res.isSuccess())
				{
					//Handle this how you want
				}
			}
		} catch (Exception e)
		{
			//If for some reason it errored while logging
		}finally
		{
			//So that we don’t accidentally insert the same logs twice for whatever reason.
			eLogs.clear();
		}
	}
}

Full code below:

	@TestVisible
	private static String ERROR_ADDING = 'Errors adding error logs.';

	/*
	Some lazy loadingcaching here so that we only check this once and then store the values for later.
	*/
	private static boolean isLogsOn
	{
		private get
		{
			if (isLogsOn == null)
			{
				List<ErrorLogControl__c> control = ErrorLogControl__c.getAll().values();
				//If the custom setting is here, assume logs should be off
				if (control.isEmpty())
					isLogsOn = false;
				else
					isLogsOn = control[0].IsLogging__c;
			}
			return isLogsOn;
		}
		private set;
	}

	//Somewhere to store this list of logs that is hidden
	private static List<Error_Log__c> eLogs
	{
		private get
		{
			if (eLogs == null)
			{
				eLogs = new List<Error_Log__c>();
			}
			return eLogs;
		}
		private set;
	}

	//Pretty self explanatory.  You only want
	public static void addLog(String message)
	{
		if (isLogsOn)
		{
			forceLog(message);
		}
	}

	//This method is reserved for when you want to log regardless of what the settings are.  Such as an error from a DML that you catch or something like that.
	public static void forceLog(String message)
	{
		eLogs.add(new Error_Log__c(Created_Time__c = DateTime.now(), Error_Messages__c = message));
	}

	//Put this at the end of your execution of code.
	public static void commitLogs()
	{
		if (!eLogs.isEmpty())
		{
			try
			{
				List<Database.SaveResult> results = Database.insert(eLogs, false);
				List<Error_Log__c> tempLogs = new List<Error_Log__c>();
				for (Database.SaveResult res: results)
				{
					if (!res.isSuccess())
					{
						//Handle this how you want
					}
				}
			} catch (Exception e)
			{
				//If for some reason it errored while logging.  You can add this error into a log if desired.
			} finally
			{
				//So that we don’t accidentally insert the same logs twice for whatever reason.
				eLogs.clear();
			}
		}
	}
}

The post Logging in Managed Packages appeared first on Soliant Consulting.

The post Set Up Postman for Optimal JSON API Debugging appeared first on Soliant Consulting.

The post An Introduction to Vagrant and Atlas appeared first on Soliant Consulting.

This means it is still a fine choice for legacy projects and/or procedural coding style.

With that said, SimpleFM includes opt-in support for the enterprise patterns that Zend Framework 2 is built for. Specifically, we mean strong SOLID principles and Patterns of Enterprise Application Architecture (in particular the Table Data Gateway pattern).

This optional material is not demonstrated in the core SimpleFM package. If you want to work with a demo, it is the focus of the SimpleFM-skeleton project, which demonstrates basic usage with the default FMServer_Sample file that ships with every copy of FileMaker Server, and can be used as a starter app for projects.

While at first blush all the enterprise design pattern mumbo-jumbo can sound overwhelming to procedural PHP and FileMaker developers, we’ve found that an experienced web developer can quickly bootstrap the web project, and then the rigorous separation of concerns makes it far easier to maintain and modify than traditional procedural programming style.

In this article we will lift the hood on the skeleton app and show how clean and importantly how intuitive the code is.

As you’ll see in these examples, after an initial burst of architectural decision-making and configuration, the code is extremely easy to pick up and modify. We sometimes hear concerns that Zend Framework might be overkill for a simple CWP project, but in practice the “steep ramp” argument is not an actual worry, given the right recipes to begin with. As an analogy, it would be unreasonable to assume that someone would have to know how to write VBS as a prerequisite to making useful spreadsheets in Microsoft Excel.

First a quick word about scalability: while using enterprise patterns can benefit a project of any size, these techniques will not change the fact that the project will be communication with the FileMaker Server XML API. There are significant advantages in terms of maintainability, security, etc. These techniques provide excellent encapsulation of all the FileMaker-specific DML, so if the day should come when some or all of the application outgrows the scaling limitations of FileMaker, the switch to an alternative data store such as MongoDb is much simpler.

Project Structure

This is the directory structure for the SimpleFM-skeleton application.

For the purpose of this post, module is the only one top-level directory we really dig into, but I’ll start out with a very brief explanation of the other top level directories first.

• .vagrant is a Vagrant cache directory that we always ignore.
• config is where all environment configuration files go.
• data is optional, is ignored by Git and is used for things like caches.
• documentation is self evident. Put things in there such as sample data and special instructions that are too detailed for the main README
• module we’ll come back to.
• public is the web root. Files in here are directly accessible in the browser.
• vendor is a Composer-managed directory where all the library code is located.

This is a very typical structure, and the modules directory is set up for PSR-0 autoloading. What this means is that everything inside a module’s src directory are classes with namespaces that match the directory names.

We can see that the application has two modules: Application and SimpleFMAuth. For the purpose of this post we’ll ignore the latter, except to say that it doesn’t have any controllers or views of it’s own. It’s entire job is to handle authentication and authorization, so it was broken out of the main module for clarity.

Focusing on module/Application, the structure is very typical as well.

• config is where all module configuration files go (things which do not change depending on environment).
• src/Application is the namespace root for the autoloader.
• view is where the html templates go. These are not classes, so they have no namespace, however, they are typically organized in the same semantic hierarchy.
• Module.php is required to define a ZF2 module. Everything else pivots off this special duck-typed class.

Once Module.php is configured, the two places that we make most changes are view/application for html, and src/Application for most other things. Let’s assume that view is self-explanatory, and move directly to src.

The src directory puts us into the pure OOP realm. All the classes in it are part of the Application namespace. We see a clear separation of concerns, as we’d expect if we’re following OOP best practices. Application\Controller and Application\Form should be fairly self explanatory in the context of an MVC (or Model/View/Controller) application.

Given what we’ve discussed so far, we can clearly see where to go if we want to manage the views (the V in MVC) and where to go to manage the Controllers (the C in MVC), and Forms, which help bridge between views and controllers, do not get their own letter in MVC, but are a familiar concept, even to non-developers. So where is the model (the M in MVC)?

The Model

When it comes to intro-level discussions such as this one, the Model is arguably given short shrift, despite it arguably being the most important. I have hypothesized that one reason that it almost must be left under-addressed is because it is the most inherently variable aspect of an application. There are two primary things that the model encompasses: the persistence strategy (how to store and retrieve information), and the domain model (what to store, and the rules that govern the what). SimpleFM provides a solution for well defined persistence and domain model with an AbstractGateway, and AbstractEntity respectively.

Domain Model with AbstractEntity

We’ll address the concept of Entity first. Entity is the OOP term for what we might loosely call a record. Generally speaking, every record in a table can be loaded into an Entity that and vice versa. This is vastly over-simplifying the matter, so just mentally bookmark the fact that we’re only making a loose association here, but very often this is exactly what happens. So we will ignore the edge cases and exceptions here. When we work with data in OOP, we need collections of objects, not tables of data. When we convert a table record to an Entity, we hydrate it, in common parlance. In SimpleFM we use unserialize as a synonym for hydrate. An Entity in its pure form does not know anything about how it is serialized, unserialized, etc. A pure Entity should only define the attributes of what it represents. For example, if the domain model has the concept of Project, there will be a ProjectEntity class which defines the properties of a Project, including its relationships with other Entities. For example, a Project might have a collection of zero or more Tasks. So it follows that we have a TaskEntity with a mandatory Project property.

In SimpleFM, we have created an opt-in AbstractEntity which entity classes can extend, and which gives it some entity-specific meta-data characteristics and behaviors. Let’s take a look at an example Project entity with just it’s properties first:

<?php
namespace Application\Entity;

use Soliant\SimpleFM\ZF2\Entity\AbstractEntity;
use Doctrine\Common\Collections\ArrayCollection;
use Application\Entity\Task;

class Project extends AbstractEntity
{
	/**
	 * Writable Fields
	 */
	protected $projectName;
	protected $description;
	protected $tag;

	/**
	 * Read-only Fields
	 */
	protected $id;
	protected $startDate;
	protected $dueDate;
	protected $daysRemaining;
	protected $daysElapsed;
	protected $statusOnScreen;
	protected $createdBy;
	protected $projectCompletionProgressBar;

	/**
	 * Child Associations
	 */
	protected $tasks;

// snip...

We see the properties grouped under three section comments. When defining a SimpleFM entity it’s important to identify which fields on the FileMaker layout will need to be updated. Clearly it’s impossible to write to things like calculation fields. For this reason, fields are segregated into writable and read-only. We also have associations, which are related entities which can be displayed in a portal in FileMaker. SimpleFM expects each writable property to have a getter and a setter defined, and each read-only property to have a getter defined, however, we omit the getters/setters here for clarity.

Because we have extended AbstractEntity, we inherit some base behaviors, and we’re required to implement some abstract methods so that the entity can be interrogated for it’s own meta information, such as the field mapping to be used for serialization and unserialization. Let’s take a look at the required mapping methods for our Project entity.

// snip...

public
function getFieldMapWriteable()
{
    $map = [
        'projectName' => 'Project Name',
        'description' => 'Description',
        'tag' => 'Tag',
    ];
    return $map;
}

public
function getFieldMapReadonly()
{
    $map = [
        'id' => 'PROJECT ID MATCH FIELD',
        'startDate' => 'Start Date',
        'dueDate' => 'Due Date',
        'daysRemaining' => 'Days Remaining',
        'daysElapsed' => 'Days Elapsed',
        'statusOnScreen' => 'Status on Screen',
        'createdBy' => 'Created By',
    ];
    return $map;
}

// snip...

These are arrays that in turn define which properties are writable and which are read-only. They also define the correlation between the property name and the FileMaker field name.

The final customization required for Project is to define how to handle the associated entity, Task. We start out be overriding the constructor, and defining the tasks property as an empty ArrayCollection. This way, even when empty, it will always be an ArrayCollection. Then we call the parent constructor normally.

SimpleFM design dictates that Associated entities cannot be persisted indirectly, but the entity needs special instructions for unserialization. We override unserialize and call the parent method. Then we handle the portal row by looping over it and adding a new Task instance to the ArrayCollection for each row.

Finally we are required to implement two public methods which define a default layout name for Project and a default route segment for use in constructing routes (urls) with this entity.

// snip...

public function __construct($simpleFMAdapterRow = array())
{
    $this->tasks = new ArrayCollection();
    parent::__construct($simpleFMAdapterRow);
}

public function unserialize()
{
    parent::unserialize();

    if (!empty($this->simpleFMAdapterRow["Tasks"]["rows"])){
        foreach ($this->simpleFMAdapterRow["Tasks"]["rows"] as $row){
            $this->tasks->add(new Task($row));
        }
    }

    return $this;
}

public function getDefaultWriteLayoutName()
{
    return 'Project';
}

public function getDefaultControllerRouteSegment()
{
    return 'project';
}

// snip...

This may sound a bit tricky at first, but I assure you, if you maintain your FileMaker web layouts and entities together, you will find that the centralization of the serialize/unserialize rules pays off many times over.

Next, let’s take a look at persistence of entities.

Persistence with AbstractGateway

In many ways the AbstractGateway is simpler to implement than AbstractEntity. The minimum requirements are that a Gateway class be defined along with a factory class to set it up, like these:

<?php
namespace Application\Gateway;

use Soliant\SimpleFM\ZF2\Gateway\AbstractGateway;
use Application\Entity\Project as ProjectEntity;

class Project extends AbstractGateway
{

}

<?php
namespace Application\Gateway\Factory;

use Zend\ServiceManager\FactoryInterface;
use Zend\ServiceManager\ServiceLocatorInterface;
use Application\Entity\Project as Entity;
use Application\Gateway\Project as Gateway;

class ProjectGatewayFactory implements FactoryInterface
{
    public function createService(ServiceLocatorInterface $serviceLocator)
    {
        $entity = new Entity();
        $simpleFMAdapter = $serviceLocator->get('simple_fm');
        return new Gateway($entity, $simpleFMAdapter);
    }
}

Sometimes the Gateway class does not need to implement any of it’s own methods, as in the example above, because there are a number of existing useful methods already defined on AbstractEntity. Custom gateway methods, however, are where you can start to define basic business logic for your model. If you application gets more complicated, you should consider implementing service classes, and keep the Gateways strictly for the persistence methods, however simple use cases often don’t warrant a separate service layer in the model.

Here’s a fictional Project gateway method, which implements some nonsesnse business logic by chaining existing find and edit methods every time helloWorld is invoked.

<?php
namespace Application\Gateway;

use Soliant\SimpleFM\ZF2\Gateway\AbstractGateway;
use Application\Entity\Project as ProjectEntity;

class Project extends AbstractGateway
{
    public function helloWorld($id) {

        $project = $this->find($id);
        $project->setProjectName('Launch web site ' . $project->getModid())
            ->setDescription('myDescription')
            ->setTag('myTag');

        return $this->edit($project);
    }
}

Conclusion

By investing in a little bit of setup with SimpleFM and ZendFramework, it’s easy to write FileMaker CWP apps with excellent encapsulation and separation of concerns. You too can have controller actions that look as clean as this.

public function listMostPopularAction()
{
    return [
        'mostPopular' => $this->itemGateway->getMostPopular(),
        'isActive' => $this->userService->isActive(),
    ];
}

The post Enterprise-quality Web apps with SimpleFM appeared first on Soliant Consulting.

…this post was mostly meant to help you feel confident that you really understand what it is that git-rebase is doing, why git-push won’t work properly after a rebase if you’ve already pushed any of the rebased commits, and most importantly, how to avoid one of the most common problems I’ve seen with people using git-rebase…

Its main virtue is that it does a great job of explaining the concept without over-complicating it. It’s not a how-to. It’s specifically written to help people who are already trying to learn git-rebase understand the concept. I’ve sent out a link to it in the Internet Archive to people learning git-rebase plenty of times already, so I thought I’d republish it here, and hopefully give it a new life until and unless Evan decides to bring back blog.evan.pro. What follows is taken verbatim from the original post:

Posted by Evan Coury on December 2, 2011

Using git-rebase without actually understanding what it does can cause headaches for you and the developers you’re working with. I don’t like headaches, so let’s take a minute to review what exactly git-rebase does.

Let’s say master is at commit C, and you create a branch feature/my-topic. So you have two branches pointed at the same commit like this:

          feature/my-topic
         /
A---B---C master

Next, you make two commits D and E in feature/my-topic and push it to your origin (we’ll say GitHub):

           D---E feature/my-topic
         / 
A---B---C master

Meanwhile, let’s say master also gets two commits, D' and E':

           D---E feature/my-topic
         / 
A---B---C---D'---E' master

So now you want to rebase your feature/my-topic branch onto master, so you run git rebase master. The result is this:

                    F---G feature/my-topic
                  / 
A---B---C---D'---E' master

The key here is to recognize that commits D and E from feature/my-topic no longer exist, and have been re-written as F and G respectively, with master’s HEAD (E') as the new base. This means that some history has been re-written. Because of this, if you were to try running git push origin feature/my-topic, you would be greeted with a non-fast-forward error. Instead, if you really need to push the rebased branch up to your origin, you’ll need to run git push -f (see note below).

DO NOT PULL, MERGE, OR REBASE FROM origin/feature/my-topic AT THIS POINT!!!

Why not? Because Git simply thinks, “Oh look, origin/feature/my-topic has two commits (D and E) that we don’t have here locally in feature/my-topic. Let’s merge them in!”… That’s a problem though, because we do have those commits, but their hashes were re-written to F and G when we ran git rebase.

So what would happen if you actually did merge? Your history would look something like this mess:

                    D---E---X---F--G feature/my-topic
                  / 
A---B---C---D'---E' master

In the above result, D is a duplicate of F, E is a duplicate of G, and X is a useless merge commit gluing the whole mess together. Using git-rebase may avoid the merge commit, but you’ll still have those pesky duplicates, so you’re no better off.

NOTE: If there are other developers deriving work from your feature/my-topic branch that is pushed; you must be careful about performing a git push -f, as it can cause problems for those other developers. Also, git push -f can be a somewhat destructive operation if used carelessly. In the context I described, it should be pretty safe, but unless you have a specific reason, it’s generally better to just leave it to the person merging your pull request to perform the rebase locally on their end. This results in master being able to simply fast-forward to the new commit (guaranteed no merge conflicts when merging into master) and no re-written history is forcefully pushed to any public repositories.

The post Evan Coury – A simple explanation of git-rebase appeared first on Soliant Consulting.

The post Annotate and Upload Screen Shots with Skitch appeared first on Soliant Consulting.

Set Up Postman for Optimal JSON API Debugging

Introduction to Vagrant and Atlas

Annotate and Upload Screen Shots with Skitch

The post Web Development appeared first on Soliant Consulting.