I am desperately missing a way to define some global variables that can be accessed from any app and are not bound to any user or app.
Think of it as global constants.
This one here seems to be somewhat related… Global variables
@sebme, this is a great suggestion. Global data is a topic on our radar. Would you mind sharing more about your particular use-case here?
Just came across this again… I would like to store a URL as a default from which certain information can be fetched - in this case not a connector but a URL to an asset path to display PDFs.
At present I need to either maintain this in a “Settings” table from which I need to then fetch the setting via a rather cumbersome procedure or define a placeholder variable with a fixed default in each app that needs it. The later entails that I need to maintain different app versions.
Being able define a workspace global value would alleviate this.
With “rather cumbersome procedure” I mean I need to define a table placeholder and then load the setting into that placeholder with the ID being the setting I want to load. And that every time I want to get something form the settings table as there is currently also no proper way to just load e.g. the entire table as an array and then select a single value out of that list by field name in the expression editor…
[Some Variable][0].[Some Field Name]
@sebme Using a statically defined table record is very similar to the global variable mechanism you are proposing. Perhaps you will have an easier time if you utilize one row with many columns. This way you can just load the “Global Variable Record” from that table On App Start in every app. Even if it needs many columns. This would also give you access to all of the data types.
I don’t think the juice is worth the squeeze when there is a pretty solid way to do this already. The Tulip team has lots of other exciting stuff in the backlog. Also, if custom expressions ever becomes a thing (please), users could create “global variables” by just having expressions which return a dedicated value. Seems like a better long term solution.
1 Like
Honestly, at this point I would prefer if some of the core functionality would be better ironed out rather than adding more “other exciting stuff”. But I guess it really depends on where you are in the development process and how complex your apps are.
Back to the topic: I would consider creating a config table and storing settings in columns the worst workaround possible for a number of reasons. The main one is long term maintainability.