applicationDataFolder comes up empty?

[macMikey]

levereApplicationDataFolder() doesn't specify what will happen if no override setting is defined in app.yml. I THOUGHT that there were default settings, but if I don't define it (at least in this version of Levure, I am getting an empty value.

[trevordevore]

An empty value is how the function is programmed. It won't return the root application data folder on a computer. Just the folder where your app can store data. So if you don't define a folder in app.yml you won't get anything back.

[macMikey]

Shouldn't it at least give me the base path? For example on a Mac, Shouldn't I get ~/Application Support/?

[trevordevore]

I don't think it should. The docs for levureApplicationDataFolder state the following:

Returns the folder where application data is stored for the application.

I don't want to encourage people to storing data in the root app data folder.

[macMikey]

Or, perhaps by default using the "name" as defined in app.yml would be good. I ran into a situation where I thought I had defined the ADF but had a typo and ended up with chaos in my repo as a library submodule got targeted (I wasn't expecting an issue with the app.yml file to cause the ADF to be empty).

[trevordevore]

I don't think we should default to the name either. There is only one place where the application data folder should be defined - the section of the app.yml file dedicated to that purpose.

My question for you is why wouldn't a configuration error lead to unexpected results?

[macMikey]

I think we're back to whatever the issue number is with no feedback for certain app.yml problems. Adding a default to the ADF would reduce that impact. Instead of my screaming "WHERE THE @(#&%*@& IS THE FOLDER?", and then debugging my way through finding it corrupting a submodule's folder, in a totally different zip code on my machine, it would have wound up closer to where it was supposed to be.

[spencerlearning]

In the new "Building Your Application" wiki page, Step 1 is "Setting up your application data folder", with a link to the page explaining how to do that. What we want to be sure is the wiki page explains it clearly and correctly.

• Building Your Application
• How do I configure my application data storage locations?

Regarding having a default application data folder, we need a name specified somewhere to use for the folder. If we use name in the app.yml, what happens if that is left blank? The most straightforward way to be sure there is a reasonable name for the application data folder is have the user explicitly define it in app.yml along with all the other settings.

On the error checking for app.yml, since application data folder and preferences filename are fundamentally important (steps 1 and 2 on the Building Your Application list), it might be good to check those two values during start up and give the developer a warning if they are empty or invalid. Beyond that, the developer just needs to be careful when editing the app.yml, at least for the time being.

[trevordevore]

What if we just throw an error if the user tries to access the application data folder or preferences and no value has been set?

A developer doesn't have to use the app data folder or preferences so I don't think we should show a warning every time the app opens. If we throw an error or display a warning if a developer tries to use the feature without configuring the app.yml file correctly then we only alert people who need to use it.

[trevordevore]

Something like this:

https://github.com/trevordevore/levure/compare/master...tkd-alert-user-of-no-settings

[trevordevore]

If Levure does start showing an alert when using the preferences API prior to configuring preferences filename then the code in app.livecodescript file that is created by the app creator would need probably need to have some code commented out. Something like this:

https://github.com/trevordevore/levure/compare/master...tkd-cleanup-app-create

[trevordevore]

As I think about this some more it would probably be appropriate for the preferences helper to display an error if you try to use it without having configured the preference filename in app.yml.

If that change is made then I think it would be best to remove all of the preferences related code in the app.livecodescript script that is created by the app creator. Otherwise you would be greeted with an error when opening a newly created application. If we have a "Configuring preferences" page as part of setup then we can show them how to add the preference helper and use it to trigger a FirstRun message.

[trevordevore]

We could add instructions on adding the preferences helper here:

https://github.com/trevordevore/levure/wiki/app.livecodescript

We could add notes on customizing app.livecodescript to trigger a FirstRun message here:

https://github.com/trevordevore/levure/wiki/app.livecodescript

To sum up my thoughts - we don't want people to be left scratching their head when they try to use an API call and it doesn't do what is expected. The data folder and prefs apis can't work without having been configured. So let's alert the developer that configuration is required if they try to use the APIs.

[macMikey]

I like that. This will also help in cases where Levure gets updated and the developer isn't close to being current, and then tries to come forward a whole bunch of commits, only to find out the hard way that something changed.

[trevordevore]

I have made the changes to the API calls. Errors are now thrown if you try to use them and app.yml has not been configured properly. I also updated docs in a couple of places.

I'm ready to slap a 1.0 release on Levure and do an official release. I will be creating a develop branch where further changes will occur. Those changes will then be rolled into master on a yet to be determined schedule.

[trevordevore]

I just tagged Levure with a v0.9.0 tag. I'm not going to slap 1.0 on it just yet but I am going to move all development into the develop branch. That way people won't be nagged to update it every time something is changed.

[macMikey]

Good idea. You might get a bunch of uptake in the near future, so there will probably be other things that come up that you want to deal with.