I’ve posted a new version of BaseElements : version 3.0.5 is available to download now. There are some fixes for issues and some other additional functionality that wasn’t there before, but the most important change is the one to the xsl import engine that we’re using.
When I was releasing the betas of BE 3 I wrote about our new xslt engine. Before 3.0.0 was released we discovered that some perfectly valid FileMaker files can generate invalid XML, so we came up with a workaround. But we also had some issues being reported where imports would fail or cause an FMP crash. Most of the failures were out of memory issues, and most of them were on windows. I came up with some sort of a solution that fixed the out of memory issues on windows.
Even though we had all of that, I wasn’t happy. The workaround for importing windows replaced our plugin related xslt engine ( LibXSL ) with the internal FMP engine ( Xalan ). This made the imports slower for everyone on windows, even though the out of memory issue wasn’t a problem for everyone. And, to make it worse, the Xalan engine seemed to cause crashes on some solutions when importing on the mac.
I didn’t like the option of defaulting permanently to any one choice, but I also didn’t want a preference that gave a choice between “LibXSL” and “Xalan”. The permanent default will mean either some users can’t import or BaseElements is slower than it was before. Having a preference with those options means nothing to the user, and just makes things confusing and forces you to go the manual for help.
The solution I came up with was my attempt at finding a combination of the best option most of the time and not forcing the users make a choice if they don’t have to. I added the preference described above to BaseElements but also added a third, default option called “Auto”. The Auto option will use LibXSL ( the fastest option for most users ) but when it encounters an error it will silently retry the same import step with the xalan engine. Only if both engines fail will the user see an error, and if it encounters more than 1 error when importing using LibXSL it will use Xalan for all further imports steps.
This has the advantage ( IMHO ) of making the import most likely to succeed in ( almost ) all situations, without any issues for the user to manage. In the very small number of situations when it would require a permanent change, you can alter it. I think it’s a good fit, and I’ve tested with all of the sample solutions I’ve got, so I’m hoping this is an improvement for everyone.
It’s an interesting process when you’re stuck with a set of conflicting ideas and goals and problems and you’ve got to find the “best fit” solution. It took quite a while of working through options and what was available within the plugin vs writing new code vs more or less preferences.