I have been programming for over 40 years. I went from FORTRAN to functional programming to object-oriented programming to database systems to client/server web pages.

A couple of years ago a company I was with bought a manufacturing control package. The developers claimed that it used a screen-oriented programming package.

FileMaker seems to be trying to be a screen-oriented programming system. The layouts are the core component of any FM application. It seems to be do-able, but I'm not sure whether FileMaker is a very good example of screen-oriented programming.

If anything, the layouts should be MORE powerful. Layouts should be able to display arbitrary expressions. Layouts should support arbitrary custom formatting. Layouts should create fields as needed rather than force you to go into Manage Database, set it up, then come back. Layouts have a fixed verticle size but no horizontal size. Window attributes are now up to scripts; these should be attributes of the layout.

Edited September 4, 201015 yr by Guest
The Topic: <a href="http://fmforums.com/forum/showtopic.php?tid/216524">Screen-oriented programming</a> was moved from <a href="http://fmforums.com/forum/showforum.php?fid/165">Recent Tips and Articles</a> to <a href="http://fmforums.com/forum/showforum.

What would you like out of FM Forums?

Sounds like you're talking about a web viewer.

This forum is "Philosophy of FileMaker". On the surface that philosophy is an integration of database, calculation, and user interface. But note that the scripts can do nothing except manipulate the layouts. Note that the validation rules for fields are data entry validations for the layouts. Darned near half of my fields exist solely to support some layout display. The entire relationships graph exists to support layouts and portals - it does not even identify the primary key of a table!

Web Viewer? I don't understand your reference. I've used web viewers; we use it to display a picture because FileMaker refuses to read a blob from MySQL.

In conventional systems, such as PHP, the code is master, interacting with the database (MySQL) on the one hand and the user interface (HTML) on the other. But in FileMaker the layout is master, and the code - scripts - can only operate through layouts. I have layouts like "Blank_User" which exist only to show nothing on the screen while my script finds the record it wants in the User table.

So if - IF - FieMaker is screen (Layout) oriented, I am trying to learrn the mental model which will operate successfully in that mode.

Screen-oriented programming compares to object-oriented programming like a marketing-driven company compares to a production-driven company. We don't sell what we build, we build what we can sell. And Apple has made a fortune following that philosophy.

[i learn from people who agree with me. I learm more from people who disagree with me. So please speak up.]

I believe you should revise some of your premises:

The entire relationships graph exists to support layouts and portals

That's certainly not true. First and foremost, the RG exists to embody the data model. Admittedly, the RG also supports the user interface - sometimes to the detriment of clarity.

validation rules for fields are data entry validations for the layouts.

Also not true. Validation works on the data level, and will be enforced regardless of the choice of the current layout.

Here's an important point that's often missed by newcomers:

Filemakers layouts are not only a user-interface element. They also serve to establish context. Filemaker is VERY MUCH context-oriented. A table without at least one layout is almost useless. But a layout can be empty and never be shown to the user - serving only as a gateway to address the underlying table.

Darned near half of my fields exist solely to support some layout display.

This too may benefit by closer scrutiny.

BTW, this *is* in the wrong forum: this section is for the "most recent tips, tricks and techniques from the databasepros.com web site". Perhaps one of the moderators would be kind enough to move it somewhere more appropriate.

Thank you. Your comments are illuminating. I do hold out on one point -

This too may benefit by closer scrutiny.

I think you mean that my package is poorly written. In general, probabably; but not on this point.

We are working on a split where the database in MySQL holds permanent data. Every release of a new version of the FP7 package relies on the continuity of the permanent MySQL data but all FP7 tables are replaced. So it is easy to release new versions. It is also easy to see which tables and fields are fundamental to the data and which exist only to support the user interface to that data.

The fact is that a layout can ONLY display something if it is static or a field (including "merge fields").

At one point we go through all the records and count them into three categories. To show those three numbers on the screen we have to stuff them into three global fields of a special table.

The fp7 file has a version number; to display that to the user it must be in a field.

Consider a case where we would accept data from an existing MySQL database. Social security numbers are stored as "537687497". To display that as "537-68-7497" we have to give it to a trivial FormatSocSec() function, but then we must stuff the returned value into a global field in order to display. In PHP we call the same FormatSocSec() function but we throw the result directly into the HTML. If FIleMaker were to accept "<>" we wouldn't need that field.

Our raw data is in a MySQL table. We need a shadow FP7 table which exists only to replicate the primary records for output formatting, like T1::Query is 0 or 1 and T1_Shadow::Query is "No" or "Yes". When we support Chinese those zeroes and ones will remain but the formatted strings will change. Yes, our packages are designed to be multi-lingual. That means separating data values from display values. It also means that all English languge text strings on any layout will have to be stored in a field.

And, as long as I've got the soapbox today, a question - WHEN will FileMaker support time zones? I would think that even a US-oriented product would realize that EDT is not the same as PST, and that the time on the FileMaker client may not match the time on the FileMaker server.

OK, your turn. Please.

(PS: Since these strings, like version number and language text strings, must appear on arbitrary layouts, they can not be in a "related" table, so they have to be in global fields.]

Edited September 5, 201015 yr by Guest

You say you're using FMP10. FMP 11 gives you the ability to display merge variables (rather than merge fields) which can be self-defining using a Let() statement in conditional formatting or simply using a script. So you don't need those global fields anymore.

But, I don't see why the way you're doing it...putting values into a global fields in a specific "display" table is a problem. Seems perfectly sensible.

FMP has the functions Get(CurrentTimestamp) and Get(CurrentHostTimestamp). Assigning time zones is up to the developer to implement.

Edited September 5, 201015 yr by Guest

FMP 11 gives you the ability to display merge variables (rather than merge fields)

Sounds good.

But, I don't see why the way you're doing it...putting values into a global fields in a specific "display" table is a problem. Seems perfectly sensible.

Works? Yes. Sensible? No. Database tables should be for data storage, not for output buffers. I have a table named "Junk" which is full of these things.

Assigning time zones is up to the developer to implement.

And I could write in assembler language and then everything would be "up to the developer to implement". C had time zone functions before FileMaker Version 1. Get Current Time Zone, tag timestamp 1 as time zone A, convert it to timezone B, all those basic tools that any deveoper needs whose clients live more than a hundred miles away.

Written 2010/09/05 14:13 GMT (Wow! What is that thingy at the end? I understand it. FileMaker doesn't. Do you?)

Andy, Cheers from Bangkok!

There is no doubt for me FM is a love hate relationship.

Simple things, time zones for one, can be a bit frustrating. But the lack of Thai unicode compatibility since FM7 is another BIG drawback for us. If your using FM, make sure you test all your supported languages for compatibility. We are now freezing our FM development to FM10, and are looking for alternatives based on this basic flaw that they seem either ignorant of, or do not wish to change.

All our Thai solutions have a Thai dictionary with words that have been imported (importation of the characters works, but keyboard entry does not), and then must be added to fields based on script steps. Writing a common text sentence in Thai within FM is not possible. I've complained since FM7 introduction about this with no answers or fixes.

Buyer be ware and check your languages and compatibility!

Our raw data is in a MySQL table. We need a shadow FP7 table which exists only to replicate the primary records for output formatting

Well, in that case MOST of your fields would "exist solely to support some layout display". And you ARE talking about screen-oriented programming.

However, Filemaker is not (IMHO) a screen-oriented programming system. In fact, FMI's official position is that:

The ESS feature set is not intended to allow FileMaker Pro to act as a “front end” to SQL data sources.

http://www.filemaker.com/downloads/documentation/techbrief_intro_ess.pdf

I certainly agree that we need more flexibility in layout design. And more functions (Get (TimeZone) would be a good example). But you need to keep in mind that Filemaker's prime mission was - and to a great extent, still is - ease of use. Comparing it to a programming language like C is rather ridiculous. Filemaker is nowhere near being a programming language. It has an Excel-like calculation engine (with far less functions) and a script builder with preset steps - and that's it.

OTOH, there are plugins to extend Filemaker's functionality, and (as mentioned earlier) you can use the web viewer to present your data with more flexiblity.

Database tables should be for data storage, not for output buffers.

Why?

And I could write in assembler language and then everything would be "up to the developer to implement".

....

Written 2010/09/05 14:13 GMT (Wow! What is that thingy at the end? I understand it. FileMaker doesn't. Do you?)

Filemaker presents a limited toolset. Being outraged isn't going to change that. Being facetious and or rude is going to limit the amount of response and help you get.

Why?

Well, I hadn't thought about it. But now I will. Because traditionally database tables and fields are permanent and shared and costly, in computer resources and management. Local variables, buffers, and the like are transient and private and cheap. You create a database field and it lasts forever, appears everywhere, and you have to document it for all the other developers to read. You create a local buffer in your code and nobody knows or cares.

Filemaker presents a limited toolset. Being outraged isn't going to change that. Being facetious and or rude is going to limit the amount of response and help you get.

My background is with the open source community. Speaking your opinion is the starting point to influence future developments. If nobody ever disliked Firefox then Firefox would never change. Even the developers of Firefox dislike parts of Firefox; those are the parts they are working on today.

When I ask a question I am asking for help. When I state an opinion I am contributing.

Yes, any package is limited. But the package evolves. Public comments on the limitations is a basic contribution to guiding that evolution. Tell us what you don't like; FileMaker Inc. is listening.

I was never outraged. I was certainly facetious, but I don't count that as being rude. I enjoy being facetious. When you are creatively facetious then I will enjoy that also.

My comment on assembler language was perhaps a facetious way of pointing out that the phrase "up to the developer to implement" can be applied to anything.

I personally find it surprising (not outrageous, just surprising) that given the way FileMaker Server is used, that FileMaker has no support at all for time zones. At debates inside FileMaker Inc. this discussion must have come up many times over the past twenty years. I am curious why FileMaker Inc. has consistantly decided against it.

I don't think that assumption is warranted. Just speaking from my own experience, which does not include being inside Filemaker, but I have been around Filemaker for decades and all kinds of forums and this is the first mention of it I've heard.