Hi all,
I’ve got a little app that I’m embedding into a “parent app”. The child app has a little data table it uses.
When I add the child app to the parent app, it will only work if I add the child’s data table to the parent app first.
Is there a way for the child app to operate on its own data tables without me having to explicitly add it to the parent app’s set of tables?
Hi Al!
For ease of nomenclature, let’s say App B imports from App A, so there’s a line somewhere in App B that says
from app_a.Form1 import Form1
It’s a design decision that apps should not be able to modify data from other apps unless you explicitly say so. Otherwise, several apps that all depend on the same app could affect each other without you being aware of it. If you do want that to happen, we make sure you’ve positively stated that that’s what you want.
So you have to import the Data Tables from App A if you want App B to modify them, even if it is modifying them indirectly by calling code from App A.
@shaun I think I’m understanding but let me explain in a bit more detail so that you can point me in the right direction if I’m doing things oddly.
In my particular case I have one main app (you call it App B above) that calls other apps via a url. The data table in my main app stores the urls for several smaller apps (you call them app A’s above).
To access these smaller apps, App B has an IFrame, within which I can embed one of the smaller apps.
This works fine except that any data tables that exist in the smaller apps have to be explicitly shared with App B.
I’m fine with this except in the sense that if I create a dozen smaller apps, then App B will have 12+ tables in it and this seems like a lot.
As you can see I am not importing other apps in code but rather storing them in data tables as urls. What I’d like to be able to do is embed these smaller apps into App B without having to add their data tables to App B as there will be many smaller apps in the future.
You can see the tables in my main app (App B) are centred around users authentication, files, and core app functionality. The “viz” tables is something that I brought over from a tiny app that I want to embed into App B. And so now I foresee my collection of tables getting cluttered in the future with tiny tables.
Is there a better way of doing what I’m attempting here?
Al
Have you thought about using one large table instead of many small tables?
You could add one app_name column to the one and only large table and use it to filter the rows belonging to each app.
@stefano.menci Interesting idea but if I follow you correctly, you are saying that all the smaller apps share a single large table (which is then shared with my main app). Is this correct? If so, I think that would work for some apps but my smaller apps will be quite different from one another and so their schemas likely wouldn’t fit nicely all in the same table.
Am I following you correctly here?
Is there a way you can do this without using iframes? Maybe you can set App A as a dependency of App B and instantiate one of App A’s Forms inside App B.
It sounds like you’re using Data Tables as a way to pass data between two apps. Perhaps there’s another way to do that in this case. If you were using dependencies instead of iframes, you could call a method on each app that knows how to store the data in its Data Tables. If you can’t use dependencies, you could set up an HTTP endpoint that contains the code to store the data. In both of these approaches, the interface between App B and App A would always be the same, and each App A would own the knowledge of how its data is stored.
If the schemas differ, then you will need different tables and the main app will have a long list of tables.
… unless you take advantage of Simple Object columns: if the difference between the schemas allows you to pack all your data into one column, then go for it, it makes tables much simpler. The only problem is that you can’t search or sort by values that are inside the simple object (unless you use SQL, which I do, which I love!).
For example I have one app that can execute different types of jobs and every job type requires different set of parameters. I started with one column per parameter, most of them were only used for one script type. Then I quickly decided to create one single Job column of Simple Object type and both the app and the table became simpler.
@Shaun, last I checked, using a dependency (library) gives access to the “knowhow” in that dependency (the code), but not the library’s own tables. Not automatically, at least.
Where library code specifies table names, those named tables are supplied by the calling app, any way that the calling app sees fit.
The calling app may supply a table by sharing from some other app, or by providing its own table of that name.
That was my experience a few months back. Has that changed in any way?
That’s quite right @p.colbert - and in light of that, the dependency approach may not work. The HTTP endpoints approach might though. And @stefano.menci’s suggestion of using Simple Object columns is also a good idea.
Thanks.
It also sounds to me like he’s trying to avoid sharing tables. If each app’s data is truly self-contained, then there’s no reason to share tables. And using iframes makes that possible, where using dependencies does not.
Yes @p.colbert you have understood me correctly. I figured that my main app (which functions as a hub or portal), would call on other self-contained apps. This is why I store the urls for the “child apps” in the main app’s database, so I can set the iframe contents accordingly. I like the self-contained idea because I can just develop my “child apps” and add their url to the main app’s table, and boom, I’m off to the races.
It will take me a bit to digest the comments here to assess alternatives. Apologies if I have not been clear.
Al
@alcampopiano, it sounds to me like you’ve hit on a great architecture for factoring “big app” functionality into smaller, more-easily-maintained parts. The more independent each part, the better your design will work.
With this design, the only time there is an advantage in putting any two tables into the same schema (app) is when there are cross-references (links, foreign keys) between the tables.
That is, unless there’s some additional Anvil-related dependencies that I haven’t run into yet. I haven’t, but then I haven’t tried your iframe approach…
@p.colbert Thanks. At the moment staff can go to the portal and (1) download files, (2) launch other Anvil apps/sites and (3) view youTube videos. Like so:
This makes the portal experience really flexible and gives staff a single place to go.
Now, the “child apps” do need to share the User table so that authentication is shared but Anvil appears to make this easy (Sharing authentication among Anvil and non Anvil apps).
But as I mention above, I don’t want to have to explicitly add a “child app’s” table to my main app’s set of tables. “Self-contained” is a nice way of putting it.
Perhaps I am just not thinking correctly and so I need to think about the above responses.
In the case described above where I open one app from another (either into an iframe or a new tab), it is not necessary to share tables between apps if you want the newly opened app to be completely self-contained.
In my case, my main app acts as a hub to authenticate users and present them with downloadable media or a a link to other apps. It stores the urls for these apps in a data table.
The only table I want to share between apps is the Users table and now this is possible from the solution here:
So all is well now. Thanks Anvilistas.
