- Yes
- No
0 voters
Please start by answering above. Feel free to discuss below...
Folders can be used to group objects in the script and layout spaces, and we can nest folders. This gives us the opportunity to create a unique name-space with the outermost folder, and then to use reliable, standard names within those folders. This works perfectly well in operating systems file hierarchies. No system allows you to use the same name within a single directory but it does allow you to use the same name. Perhaps Claris could implement the same rules.
3 Likes
I agree with @Malcolm that it would be nice to have name spaces to scripts and layouts… but they don't exist within a file. While you are currently allowed non-unique names, electing to use a non-unique name can bring difficulties when referencing a layout or script by name.
1 Like
It is also worth considering how FileMaker Pro resolves references to such objects when importing or using the clipboard to replicate them in another file.
I understand the analogy with operating systems, but given how resolution takes place for such things, I've always sought using unique names for those, despite being free to duplicate the names.
As @bdbd points out, there are things where uniqueness matters, such as layout names for API calls and script names with FMPurl (adding to the already possible indirection we get from running perform script by name or go to layout by name).
That said, I am not opposed to duplicate names for folders, both for scripts and layouts, but even for those, if you paste them in a file where another folder with the same name exists, FMP is adding a number suffix (I'm not too sure why it does that, but it does).
It would have been better if they did, but I don't think they they can start now, when there may be solutions that have them already.
Well, they could force rename some items to enforce uniqueness. It would be disruptive for sure, and we would have (the ones relying on duplicate names being a "feature") to watch our back, but if they wanted to do that as part of a migration from the .fmp12 file extension to the .claris one, I would not object.
1 Like
The two situations above are a good discussion point.
API: API access should be carefully controlled. API should have tightly limited access to the database. Layouts designed for GUI should not be re-used for API. Layouts for API access should be designed especially for that purpose. Accounts accessing the database via API should be designed for that purpose. Scripts that are open to the API should be designed for purpose. Of course, creating a unique name to ensure that the correct object is used is an important requirement for API development.
Indirection: To use Perform Script by Name you have two tasks: (1) Know what the script name is, and (2) to provide the name to the script.
For example, you could generate a name, by combining units. One set maybe ("create","edit","delete") and another maybe ("record","foundSet"). The user chooses one from each to build the name. That's fairly brittle because names can change, breaking your code. One way to protect against brittleness and hard-coding would be to store IDs and using the ID to extract the script name. At that point, the possibility of a duplicate name would really bite you in the bottom. The first script with that name will be called, regardless of which ID you used. Now you have to ensure that scripts being called by indirection always have a unique name. It would be much easier, and safer for us, if Claris included an option to Perform Script BY ID.
Even though these situations require unique names, I don't want to see that requirement forced on us. I use duplicate names for layouts deliberately and don't want to lose that functionality.
MBS Plugin has functions to find duplicate names in scripts or layouts 
3 Likes
The magic broom for good housekeeping 
.
Notice that when you duplicate a folder in layouts or scripts, the only object that gets " copy" appended to it is the top level folder. Everything within the folder retains the original name.