I don't believe I would want to put them in a separate folder. How many files do you have? I have one separated solution with 1 interface and 3 data files (many tables), but the logic was for different parts to be shown to different users (accounting doesn't need to see everything, for example). But all files would be in the same "level".
Security must be everywhere and the logins must match for your DATA to automagically appear in your INTERFACE. Otherwise the user must login in again to see the data on the layout where it should appear.
Tx a lot I'am surprise and very happy that you took time to follow my question.
Yes : I have 1 interface and 3 db (with many tables)
I wanted to seperate (it's my first runtime solution - a freash baby!!!) the back-end dbs from the front-end.
I tough that runtime solution would put all things in one big file (within the runtime file). So when I saw that my db where visible in the root level of my project, I relinked my project and put my db in a folder named DB.
Just to saw again that the runtime machinery was puting them back in the root level. And - to that - we actually can even open the ".fmpur" files!!! I simply don't understand!! Frankly, when you want a runtime solution for customer, you don't want them to mess around with files and db, right? Sure I'am at a test stage, but that's not what I wants.
Secundo: sure I wasn't testing security : but how do you "hide" your back-end data from been opened just like a stupid spreedsheets!! I just want my customer to double-clic her solution and voila. Not only this, but it always ask for files, and files, and files (see what I meen). And for security, if you put them everywhere, in synk (all db files : gui and data, shares the same priviledges sets, is that correct ?), it still ask twice the password, wich is very anoying.
I read a lot from you and many pro, and as a "normal developper" using MVC (Model View Controller) the promeses of data separation is more than acceptable, it is crucial. So at home, for me and my wife's buziness, it's ok... But for customers, with many employees, runtime solution in that maners is not very satisfying.
But I'm listening to your advice and wait if I can go in sep-data.
tx a lot again. Hope I don't confuse you, can't wait from your expertises to guide me.
have a nice day
Yes, the "binding" process allows the runtime engine to open ONLY those files you have 'attached' to it. However, any FMPro or FMPAdvanced (or possibly FMGo - I just have not tested) can open your files as long as you have the login to do so. The 'engine' at that point is ignored. This is a good way to "bind" and make changes with your FMP. Then you may not need to 'rebind' after changing.
You can't hide from opening the data files, because the UI file/db needs to open them. But if you require a login that is not known to the user, then they cannot directly open the data files. But for security, you can put limits on access to layouts and other objects in the DATA files. The user won't be able to see (directly), the data, but only through the UI.
To me, MVC may not mean the same thing to you. I just put the Views (layouts) in the Interface. The Controllers are basically a set of script steps that "direct" the user. Look at some of the Starter Solutions for opening scripts to test for platform and direct to particular layouts for Pro, Go, or Web Direct. That would be a controller, guiding the user to the correct layout (or other action). That can be extended for other 'controllers' throughout the solution. Controllers would also be in the Interface. The Model is the queries, including finds/sorts and filters on portals or any scripts & calculation that works with the data (other than controlling the flow) and for the most part is in the Interface as well. The DATA file has very little to do with MVC. The data is acted upon by the Model & Controllers for the end result: the View, which all are in the Interface.
And there are as many opinions on how to do separation and/or MVC as there are developers. So listen to others, too, before forming your own.