Developing for Repurposing

[dmontano]

I stumbled along something that may or may not be a good thing in terms of developing a solution. It started with my attempt to streamline the creation and maintenance of scripts. I explored parameters and now I think they are awesome.

But when parameterizing those scripts I realized, all of those buttons had to be hard-coded repeatedly in the script parameter dialog wherever the button was to do the same function. If a layout changed, I would have to change the script once, but all the button parameters would have to be updated one-by-one. A lot of work.

Furthermore, I looked at the solution and realized there were quite a few instances where the parameter value was specific to the company the solution was for (open URL - for example). So, I built a separate file and have called it "company_preferences" and named the file by the company's name. I built a GLOBAL field for the web site.

Then back in the original file, for the script parameter value I am referring back to this "company_preference" file and the GLOBAL web_site field for the parameter value. That way, if I change the "company_preference" web site field, all of those parameters referencing it will be updated and reflected immediately and I do not have to revise each buttons parameters with the new web site.

Some time ago I built a separate table within the solution called "global_graphics" that would allow my to change a graphic once, and the solution will reflect that change. But, I could take it a step further and break it out into a separate file, or actually in the new "company_preferences" file and include all of the graphics, and parameter values there.

I decided to break the preference out as a separate file so I could change 1 field in 1 file and it would affect any file or files that rely on it.

Does this make good sense? Or am I missing some critical issue? I have no real-world experience with how globals behave in a multi-user environ, but my understanding so far tells me that this would not be a problem as I would want these values to persist. If something did change, like the main web site, then that would have to be done after business hours or such. If I tie script parameter values to this file - is that a problem?

Before I go head first and build out this way - I am soliciting for any and all input. Any comments are appreciated.

Thanks.

[bcooney]

I think that you are on your way, although specifics would assure that.

It is routine to have a table (not necessarily a separate file) for preferences. It is also routine to have corresponding global fields or global variables (if you don't need to build a relationship or show on a layout) for those preference values. Then, in an "Open" script, one that runs when the system starts, all the global fields (variables) are set to their corresponding preference values. Some use global calc fields that equal the corresponding preference field rather than a series of Set Field steps.

Having those values in globals frees you in many ways, especially from context issues.

Remember, globals are session specific. In a multiuser environment, each user has their own set of global values (although they may be identical). That means, if a preference value is changed, unless a user runs a script that resets the global to the preference, they maintain the previous pref value in their global.

hth,

Barbara

[dmontano]

Thanks Barbara - I appreciate the info.

I am wrestling with how to control the parameters for the layout names in the "main" solution via the separate "preference" file.

I have got it to work (using a global field for 1 of the layout names in the preference file that I manually type the layout name in), however, I find myself going back and forth from preference to main file to make sure I obtain the exact layout name.

As it stands, I think I will be building 1 global field in the preference file for each layout where I will want to control the parameter value in order for the parameter to be picked up. Does that sound correct? If I have 22 layouts defined by unique name in my "main" file, my preference file would need 22 "global" fields in which to hold their unique name?

Is there a way to implement a functio nthat returns the layout name value from this separate file? Another words, while in my preference file, can I build calculation that returns the layout name I assigned in the "main" file?

Thanks again for any insight.

[comment]

Don't overdo it. There's a fine line between making a solution flexible and rewriting Filemaker.

[dmontano]

Thanks Comment.

Your advice - as always - is respected and appreciated.

I had over 330 scripts - so I jumped into parameters to squish that growing problem. I can see parameterizing helping to reduce that count.

Now for the embarrasing part - I have over 140 layouts. I am "now" learning to consider using table view for DEV only tables - but that distinction has been unclear to me as I was building out. So, I defaulted to just putting an interface screen on any table I built since at least I was going to interact with it. I can see now that I also extended my maintenance list by doing so. So, your advice about not overdoing things really rings home.

If I were to create these global fields to hold layout names - and somewhat stop at that - does that sound reasonable, or is that borderline in excess?

Do not mean to beat this into the ground - just poking for any further clarification.

[bcooney]

I wouldn't suggest storing layout names, anywhere. Anytime you "hard-code" a value that you can change, you risk something breaking when you change the value.

Why, again, are you trying to store layout names?

[comment]

LOL, you are asking how much is too much. All I meant to say is that decisions should be made while considering the needs of the current solution, not of a possible next one.

I didn't catch what benefit is there to putting layout names in globals, but take into account that changing a layout name is automatically carried over to scripts using it. That won't be the case when the reference goes through a global field intermediary.

[dmontano]

Maybe I uncovered an interestiing shortcut....I doubt it, but I might as well "think" i have done something streamlined for a moment. Okay that moment has passed. Maybe this is well-known, maybe this is ill-advised, but here is what I am doing with the layout names...

In my main file, I have about 140 layouts. After I cull that down to useable layouts, I am estimating about 80. Instead of typing "Vendor Company Profile" in one of the button's parameter value, I reference the parameter value to be "what" is stored in the second file, in a global field for that 1 layout: Vendor Company Profile

If I ever change the name of the layout in the Main file from "Vendor Company Profile" to "Vendor Profile", I only have to revise the global field in the second file, because my parameter is referencing the value in the secondary file. I am doing this because.. even though if I change the name of the layout in the main file, the script value referencing it will be updated, however, not the "Vendor Company Profile" text string placed into the Optional Script parameter dialog for that button.

This way I would not have to open that similar button on multiple layouts to update that one parameter. Let me guess - there is already a way to update the parameter and I missed the boat on that?

I understand the downside is I am dependent upon the second file's constant existence, but since I am building a modular solution where the 1 Preference file would hold graphics and client specific data, wouldn't that allow me to port to another client much easier? I am just exploring - maybe I have wondered off the cliff - maybe not. Any "redirection" of my efforts is greatly appreciated.

[comment]

In what situation would be a layout name as script parameter useful?

[dmontano]

My house of cards is about to come crumbling down isn't it? Now you have me thinking.... this is where my head starts to hurt.

Filemaker does a great job of reolving TO, tables, and field references. Then I got into parameters - just a couple of days ago - and discovered they do not always resolve themself. Especially the way I was entering the parameter value.

In my case, I changed a layout name (as a test) and I saw the script referencing the layout changed accordingly - but not the hard coded parameter I typed for the button.

So in this example, or better, my predicament of having many things built that I am rebuilding - this would have saved me the hours of specifying the Optional parameter value for each button.

I can see an experienced developer probably doesn't deal with the Frankenstien I have created, and would have solidly laid out a few layouts and parameterized them and then duped the layouts from there. I fall into the "learn-the-painful-way" group.

But, that aside, I do think there is merit to the idea. I can see the "need" or "want" to change layout names and having a mechanism in place that facilitates that process - sounded good to me.

But let's say I were to somehow create a basic go-to-script as I have described, I do not know but suspect there might be a way I can use it as a subscript in other scripts that have the same step required. Maybe I just "jumped-the-shark" but I think I could assign many of my buttons the same parameter value so I could in theory change the parameter value in one place and affect many.

Lastly, I do think this has merit or potential considering a multiple file solution that is a candidate for repurposing for another "client".

Building upon the separate "Company specific preference" file, elements that are pertinent to the customization of the file for porting is something I am exploring.

Hopefully I have used enough "big" words in the absolutely most inappropriate context (misspelings and all) to have you thoroughly confused and you will just say that it was a brilliant idea!

Okay, now feel free to bust this bubble.

[Vaughan]

"Filemaker does a great job of reolving TO, tables, and field references. Then I got into parameters - just a couple of days ago - and discovered they do not always resolve themself. Especially the way I was entering the parameter value."

That's because tables and fields are internally referenced by IDs, not by their name. Layouts are also references by their IDs, which is why Go to Layout steps don't break when they are renamed.

However what you're doing with layout names is bad design. As you've discovered, it's fragile and easily broken and does not allow for change.

As with Comment, I cannot see when a layout name would be useful as a script parameter.

I often reference TO names as a method of selecting layouts, but never the layout names. But I'm very careful about it. I make one script as the "select the layout for XXX" function, and always reference this script whenever I need to do XXX. That way if things do break they only break in one place, and they get fixed in one place.

I think that this is the kind of modularity you should be thinking about.

[dmontano]

Okay, can I have a suggestion on what to use as a script parameter for a button that will be assigned to a script that I want to take the User to a layout named "Vendor Company Profile"? I can not use the TO as I have multiple layouts associated with that TO.

Do I use the specify the optional script parameter as a calculation that "gets" the layout name?

Any help appreciated.

EDIT: I found out the Get (LayoutName) won't work. I am curious then how to create a "Go To" script that uses parameters wihtout having to edit each buttons parameters if something where to change or need editing?

Edited July 30, 2008 by Guest

[Fenton]

I would agree. FileMaker's internal ids protect you from breaking things. Once you step outside that, you have to be careful, especially about changes. I have used script parameters to control navigation on occasion. So that rather than having 10 "Go to Form View of a particular table" scripts, I could have one, controlled by script parameters. In that case it would be driven by a button, with an easy to recognize script parameter. Example:

If [ Get ( ScriptParameter ) = "Contact"

    Go To Layout [ Contact ]

Else If [ Get ( ScriptParameter ) = "Company"

    Go To Layout [ Company ]

etc.

End If

Adjust Window [ Resize to fit ]

(Otherwise you could just attach Go To Layout [ ] directly to the button.)

It is NOT going to layout "by name", it is using the drop-down list of layouts. So it will not break if a layout name changes. The only problem is remembering to add the parameter to a new button; but you usually copy/paste sets of buttons from on layout to another, so this is usually fine.

No, it's not very high tech. And I've seen more comprehensive solutions. But I haven't really felt the need personally to spend a great deal of time on them. I just don't find standard navigation to be such a big deal that I had to built a complex (and breakable) modular structure to handle it. I guess it partly depends on this size of the solution. If I did use such a system, it would be in a separation of data model.

[dmontano]

Thanks Fenton for the input.

So if you are using the layout name as your parameter to alleviate the 10 scripts in your example. That is part of the beauty of parameters - right? But now you have to edit all button instances that rely on that one parameter. If you had (140 layouts) that is a lot of buttons.

All I wanted to be able to do was control that parameter without going into the button since filemaker will not resolve if I change the layout name.

So, I create a global and reference that field as the script parameter. Doing so actually creates an environment where I do not have to edit any more - if I choose. The buttons parameters are attached to a stable value in the global and that is what the script is referencing. I could change the layout name to whatever I wanted and I would not have to edit any of the buttons that would have otherwise relied on it.

I understand using layout names is troublesome because of the referencing issue. Doesn't what I am proposing (and seemingly working) actually circumvent that problem altogether? For example, in your example posted, if you changed the layout name - you HAVE to change the parameter to match AND the script.

I am not trying to discount all of the issues brought up - I value them and am more interested in completely understanding why? I could used a completely arbitrary text string to get the results I want - I express this point to toss out the association to layout names.

I could have simply have said button 1, or button 2, or widget, etc. The point is - I no longer have to be 'literal' in the script parameter - I am letting the calculation do the work.

I think my inability to describe accurately may be the problem - and perhaps my use of a layout name in my example as the parameter is too closely tied to the long standing knowledge that layout names are troublesome. Guilty by association?

All comments appreciated.

[Ugo DI LUCA]

Hi,

Everything hardcoded should really be prevented I'd think.

But there are lots of instances where we're using them ( Layouts, fieldnames, valuelistItems )

There's an interresting function by Fabrice Nordmann Here which covers this need. Basically, give its name, get the ID, so that you'd never be caught anylonger with this problem.

As for buttons scripts, I avoid repeating processes by storing any parameter in a separate Table. All values are passed to a global repeating Variable at the beginning of the session, and the script parameter passed now is nothing else than a Custom Function MyParam ( n ) where n targets the variable iteration to be evaluated.

The truth is that I can't avoid hardcoding as these parameters actually are text formulas, but there's no need anymore to go back in layout mode to change any parameter affiliated to a single button.

These external parameters are really handy, it's so easy to manage when you're used to them. They can even be given different parameters according to the User in very short time.

HTH

Edited July 30, 2008 by Guest

[comment]

I see three distinct situations here:

1. The button goes to a specific layout in order to do something there - here, selecting the layout is an integral part of the script action and should be specified in the script itself;

2. The script goes to a layout as a navigation step. This should be specified as direct button action. The button can be then copy/pasted to any potential origin layout;

3. Same as #2, but navigation requires an additional step, such as Adjust Window (Fenton's example). This is an issue that is best avoided (easy to say...), or at least minimized (do you really need 140 layouts?). In any case, there is no really good solution for this, and one needs to choose the least complex alternative IN THE CURRENT CIRCUMSTANCES.

considering a multiple file solution that is a candidate for repurposing for another "client".

IMHO, this would be a legitimate consideration if your purpose is to produce a template. But when you are developing a custom solution, such approach is unfair to both your clients.

At the end of the day, Filemaker is NOT an object-oriented programming environment. There is a tendency among some developers to correct this "flaw" by devising elaborate methods that would allow them to re-purpose just about everything. But these methods carry a price: you achieve simplicity in one place by adding complexity in another. You need to decide whether the price is worth paying, in each individual case.

[Fenton]

For example, in your example posted, if you changed the layout name - you HAVE to change the parameter to match AND the script.

No, I do not. The go to layout is not using go to layout "by name", it's the normal Go To Layout, where you chose the layout, but FileMaker is storing the reference id. I tried to make that clear, but the methods look much the same when you type them in a post (I did not put quotes around the layout name).

I would not need to change the script parameter either. It's independent of the layout name itself, and is fairly short and simple.

I mostly just use this for go to Form and List view scripts; otherwise there's a lot of those. And, yes, I could avoid them by doing a 1-step script step attached to the button, which I often do when using Go To Related Record from a portal to a form view (one form to another form). But I like to Adjust Window [ Resize to fit ] when going from List to Form and visa versa.

Yes, I would need the same buttons/parameters on layouts. So I copy/paste the set, and make any adjustments needed (few). Yes, that's a little work, but less than a full-blown navigation system. Or, if a complex solution, I might have a "control panel" window, and put the buttons there. I don't know that there is a "perfect interface for every solution." So, by all means, try whichever you think.

[dmontano]

Thanks all for the input. I am sure I have misconstrued and even rephrased in error - I have been staying up very late and trying to wrestle with these concepts and all the feedback. Sorry Fenton, I see what you are saying.

As for my reference to "client" - that was the easiest way for me to get the idea of divorcing the context idea across to those who might read the post.

Since I am building a modular solution, I recently have been thinking that a central file that holds "preferences" and "metadata" about the different "files" within the solution "might" be an efficient way of reigning in the multiple files in the 1 solution.

My Vendors module (1 file) has over 26 tables, 330 scripts, 140 layouts, and so I decided I MUST explore ways in which to economize, streamline, simplify the development of this module because... I will be replicating much of the development in other modules that comprise the solution. My focus right now is to reduce the clutter, the layouts, and simplify. Now, I would rather spend 2 hours on one good multi purpose script, rather than create 40 scripts in 1 hour.

I have identified and partially created over 16 files or modules. I know, I know - sounds like an ERD or structure problem. Welcome to my world of learning. I will be able to go back now to those other modules since I have learned "a little" more and see where some of those modules can be consolidated into other modules. But all the time that I am working in my current "module" I am trying to keep the other modules in mind so I can leverage the sweat equity I am spending in the Vendors module into the other "modules" or my ill-referenced "client" example.

My target is to have no more than 8 files when I am finished. 1 of those files I thought could be the "preference" file I have mentioned that all the other files will tie into.

I choose the "term" client to get the idea across that I wanted a great deal of arbitrary meaning to more and more of what I want to do. Abstraction?

I have found most all of my files were getting too personal when there was no real need to do so. For example, I would create a field and enter the role of the person along with the company they worked for to establish some meaning to what the field was, for example, in one table I need to have 2 coordinators, but each representing a different company, I use to do something like this:

acme_floor_company_coordinator

vendor_coordinator

Now, I am trying to unpersonalize the field data but still be clear as to the role:

our_company_coordinator

vendor_coordinator

It is not perfect, nor exactly what I have done, but I hope it gets the idea across that I want to untie as many developer dependencies on resolving references.

With all that said, if I specify as an optional script parameter assigned to a button that references a global field in my preference file for its value to be passed to the script in the main file - is that a problem?

[Vaughan]

"I have found most all of my files were getting too personal when there was no real need to do so. For example, I would create a field and enter the role of the person along with the company they worked for to establish some meaning to what the field was..."

I do not work this way.

Data is only stored if it is need for some kind of OUTPUT. If some information is not needed for a report or for a business process, then it is not needed in the database. It's deadwood; an unnecessary work load on the users, on the servers and on the developer.

The speed at which users can distinguish between useful fields and all of the other crappy fields on their screens is astonishing. It's interesting going through older databases and seeing which fields are empty except for the first dozen or so records.

It's part of a developer's job is to weed these out ruthlessly.

[dmontano]

Hi Vaughn,

The two fields I used in the example are needed fields. I think my explanation was very poor and misleading (after I read your post I realized my communications skills need refining). I meant to say my "field names" in the Define Database Dialog.

1 field holds the name of the person who is coordinating the event for "Our" company;

Second field holds the name of the person who is coordinating the event for the "Vendor".

I was referring to the fact that I was personalizing the solution by placing the name of our company in the field label along with the role of the person to distinguish it from another similar field. Only as an example of me trying to get towards as much abstraction as possible.

Example of my old way:

Acme Company Coordinator: Jane Doe (Our employee)

Vendor Coordinator: Billy Bob

Example of my new way:

Our Company Coordinator: Jane Doe (Our Employee)

Vendor Coordinator: Billy Bob

The premise is that a solution is not portable for reason such as this. In an extreme case of developing a solution modeled from another past project would lead to such instances as this - simple things like a field name label was personalized for a previous project.

I am quite sure that many developers do not start from scratch when a new client ask for a solution and the developer already in the past has built some tables that are reusable.

[Vaughan]

"The premise is that a solution is not portable for reason such as this."

The end user need never see the actual, internal field names (except perhaps when exporting but that can be scripted anyway). I would not consider a solution "not portable" based on field names. The field label that the user sees on layouts need not be the same as the internal field name; often it is not in my solutions, though I try to keep them similar enough to make maintenance easier.

I tend to use descriptive field names, but keep them generic as possible. I use works like "local" or "domestic" or "customer".

[dmontano]

Hi Ugo,

I think what you have described is what I am tossing around in my head. I do have a separate table that resides in a separate file for the purpose of holding the parameter value in a global field. This separate file use to be "just" the start-up file that provided a "fork" - if you will - to direct the User to certain "modules".

When I started to rebuild my scripts to incorporate these new "parameters" - I had to figure out where to build the table to hold them. My choices were:

A. Create a separate file to hold this "parameter table"

B. Create a table inside the specific "module" file

C. Create a table inside the "master" start-up file.

I choose "C" because my other "modules" (files) would - in my mind - be constructed in the same fashion and would need similar access. Sound reasonable?

I have never launched a solution in either peer-to-peer or via server - so I have no experience whatsoever. Therefore, all of the contributors posting here have been a great value to me. The issue of globals: clearing them, loading them, and where to place them is vague to me. In addition, not knowing what to build for the start-up sequence (which files etc.) is compounding my confusion.

If anyone can comment on what I have described regarding:

a separate start-up file that houses the script parameters in a global; which another separate file of my solution depends on is "generally okay" or is it going to be problematic - I would appreciate it.

Thanks

Edited July 31, 2008 by Guest
Bad grammer and spelling.