1 2 3 Previous Next 35 Replies Latest reply on May 19, 2015 6:24 PM by jdw1

    Using FM via PHP, wrapping my head around it


      I built an extensive IWP public site. This year a web designer will make a new PHP face for it. They'll do PHP and I do the FM side and I need to make a mental shift of gears. I've answered some of my own questions by experiment but just because I CAN do something one way doesn't mean it's the best way. Would appreciate any input on these thoughts on PHP->FM being different from direct use of FM (even if by IWP or WebDirect).


      1. Scripting mostly being in FM: I'm envisioning keeping scripting mostly in FM. That PHP will simply tell FM it wants the pledge total from last year for the bowlers on a given team (it's a fundraiser site), so the captain can see what he did last year. FM would run a script that would go to a layout that gives the bowler IDs for that team. Then take each bowler ID in turn and go to a layout that lists their pledges. Get the total for each one, add up a grand total, and say back to PHP what the result is, or an error code that that team couldn't be found or whatever. (There are better ways to structure and script this, it's just an example.) I assume having FM do all that makes more sense, and I hope so because it will make it easier for me to build changes or new features.


      2. Layouts: Since FM does so much by layouts I assume I'll still need to use those. As in the example above, even when a layout is only accessed in a script and never actually seen, FM still operates by layouts. So even though no layouts will be seen at all since PHP is the user interface, I still need to use layouts a lot.


      2B. Similar to remote control: To a large extent the new PHP will be a remote control driver of the layouts that were presented via IWP last year.


      3. Continuous sessions: I assume that when a PHP web session opens an FM session that it's much the same as a physical user starting an FM session. I mean, if PHP opens a session and asks to get some user account info for John Smith, and, as part of the FM script that gets that data, it goes to the User Account layout, then the User Account layout continues to be "open" just as if a user had gone to it. So if the next PHP command triggers a script that, A: goes to the Middle Name field, B: highlights all, C: Copy, and then delivers that info back to PHP, it will get the middle name for John Smith because it left off on the User Account layout and specifically on the John Smith record.


      4. Multiple sessions: Continuing on that question, if multiple people come to the site at the same time (obviously the idea) then each PHP session opens its own FM session. John Smith's session and Mary Doe's session don't get mixed up just like they wouldn't if they were users directly in FM.


      5. Closing sessions: I suppose just like with IWP, if the user is nice enough to hit the logout button then PHP can close the FM session. Otherwise we're stuck with waiting on the timeout, and there's the usual tradeoff of not having too long of a time-out so there aren't too many open, abandoned sessions.



        • 1. Re: Using FM via PHP, wrapping my head around it

          Hello, njem.


          Coming from an IWP background, you won't have the necessary framework for a PHP / CWP setup. As a result, many of your assumptions are mistaken.


          1) Scripting can be kept on the FileMaker side if you want, but often, it's more efficient to work entirely within PHP. If you don't need something from the database in order to make a function work, for example, it's usually better to write a PHP version of the script and just let the PHP engine handle it. Even if you do need something from the database, you often get better performance just fetching the data and then manipulating it through the PHP code. (There are exceptions.) Not to say you can't work things with FileMaker scripting; the API provides for that. But it's not always, or even often, the best option.


          2) Yes, layouts are definitely needed. Most of the commands in the API are structured to call the database through a target layout. This does not mean, however, that your layouts will in any way resemble layouts users might interact with in an IWP or FileMaker environment. For performance reasons, a CWP-accessible layout should contain only the bare minimum needed to make it work. As a result, you'll often have different layouts from the same Table Occurrence (TO) for different sections of a web site (for example, one for a list view and one for a form view).


          2B) See 2 above. No, you will want minimal layouts that have only what the PHP engine needs. Your old layouts should most likely be retired.


          3) This assumption is incorrect. Because the PHP environment operates as a stateless connection, the server retains no information about the client once it delivers the requested information back to the browser. Each call to the database starts a new CWP connection. (Such connections persist for a few minutes, but let's not muddy the water.) As a result, you'll need to use PHP sessions (via the $_SESSION array) to retain user login information. Any web programmer who is familiar with PHP can set this up for you. But it's not automatic, and it's not part of the FileMaker API. (There is a qualifier: Setting up security to access the FileMaker database is a little unique to the API, and would be something to learn for someone not familiar with how the API works.)


          4) See 3. This will have to be done as part of your PHP code. It's not part of the FileMaker API. But yes, the $_SESSION variable tracks unique users; that's its purpose.


          5) See 3 (again). Connections will automatically terminate, and the session limit is not really an issue under most circumstances.


          Your question is phrased in such a way that it reflects an intent to split the work between yourself, doing the FileMaker programming, and a web designer, doing the web side. Unfortunately, this plan may have a significant flaw: You still need to connect the two. PHP can't fetch data from the database without establishing the connections and parsing the results. If your web designer wants to make you a new site, you'll need to have someone familiar with the FileMaker API work in the database connections. Most PHP web designers are not, so you'll either need to learn the API yourself or hire a consultant who knows it.


          I suggest you get some documentation on the API and review how it works. Tim Cimbura has published a nice collection of documentation on his blog: FileMaker Custom Web Publishing - Cimbura.com, Inc. Tech.





          • 2. Re: Using FM via PHP, wrapping my head around it


            Thanks for the holiday weekend answer. We're on a very tight schedule so I appreciate it. But it makes my life much more complicated. The core is this lack of persistent sessions. That's a radical mental shift. It seems contrary to my, perhaps mistaken, understanding of FM as well. Things like global fields and global variables are important in FM, and disappear when a session ends.

            And anything that is a sequence would become difficult. That you can't get to a layout and record, then come back and do something more and count on that same layout and record being the current state is radical. A team captain might indicate who they are, to get to their list of teams. They pick one of their teams. They pick a bowler on that team. They click to see how many pledges that bowler has. Without continuous sessions I need PHP to restate all those criteria, or have FM save it all connected with the PHP session #.

            I suppose that's all possible but seems more complicated, and a radical rewrite of scripts and layout structure, or as you say rewriting scripts in PHP.

            For one, we don't have time for that. (We were just looking for a graphics person to pretty up the IWP/WD when we were offered a whole new web page face, management said "sure", and now I'm figuring out what complication that means.) It also seems like reinventing the wheel since it all works now, it just needs a pretty, more web-typical face. Also in our case we have in-house FM resources (me) but not PHP resources. Future mods would hopefully be nearly cosmetic on the web side and any mods to logic would be on the FM side.

            So...I need to explore an alternative if only to confirm if it's impractical and shutdown this whole change. You say sessions stay open for a bit. Is there a way to ping and keep them open? That way the new web face would mostly just remote-control the old site (in a virtual sense and with some mods). And would that work for multiple people at the web site and each with their own PHP session to FM. For confirmation I would have PHP & FM pass the PHP session # back and forth with each command to verify session consistency.

            My crude PHP -> FM test must have worked within the few minutes you say connections persist. I do have Stark's book and articles and materials from FileMaker Inc. I've never seen anything in them about how to deal with the fact that sessions aren't persistent. Or maybe I missed it because I didn't realize the significance.



            • 3. Re: Using FM via PHP, wrapping my head around it

              Tom -


              To a certain degree, yes, you are "reinventing the wheel". A CWP interface is much more like a traditional web site / page than IWP ever was (or WebDirect is, for that matter). So you definitely need to "wrap your head around" the fact that the web is stateless. It does not maintain communication between the client and the server, by design. (There are some technologies out there that mimic state, like AJAX - or IWP - but in its base nature, the web doesn't maintain state.)


              So what you're calling a "session" has a different meaning in the web world than it does in the FileMaker world. In the FileMaker world (including IWP and WebDirect), a given client maintains continuous communication with the server. This is the basis for your Admin Console "Clients" page - where you can see everyone who's connected.


              In the web world, a "session" consists of a special memory array and a token. The token is a string of characters that uniquely identifies the client to the server, and allows the server to maintain certain information about a client as that client moves between pages. All web languages, including PHP, provide some method for storing a session. But it does not mean that communication is constantly maintained. Instead, it means whenever a client requests information from the server, it passes its session ID (token) to the server along with its request. The server then passes back the requested information in the context of the user's saved state.


              However, that means that you have to encode everything about the user's session into, in the case of PHP, the $_SESSION array and have the server save it. You can't just rely on the typical FileMaker tactic of using global fields or variables. As soon as the connection is severed (typically, within a few minutes), such globals will cease to exist.


              There is one other option. You can create a Sessions table inside your FileMaker database. Then, you can store necessary information in that table based on the user's login information (perhaps using a token). That way, whenever you move to a new page, you can instruct the page to fetch the user's Session record and the appropriate saved information. This is, however, likely to be significantly slower than using the more typical web approach (since it will involve an extra trip to the database when you enter every page).


              So, short version: Yes, you can maintain unique identification of users on a CWP web site. It's no different than, say, an eCommerce site where your shopping cart is saved as you pass between pages. However, you will have to do it using web programming techniques, or use a Sessions table. You cannot rely on globals.


              Now, let me take your example of a team captain who needs to fetch a list of teams and then drill down to see the bowlers associated with those teams. You do not necessarily have to store all that information in $_SESSION. Here's how:


              1) Store the team captain's ID (from the Captains table) in $_SESSION when he logs in.

              2) Whenever you move to the next page, that information is passed along.

              3) By clicking on the link that says, "Show me my team", you fetch the Captain ID from $_SESSION and embed it in the newFindCommand call to the database.

              4) Once the team comes up, you still have the captain's ID in $_SESSION.

              5) In the link for the bowler, you still pass along the captain's ID.


              This is how "sessions" work in the web world. The $_SESSION array holds the data you want to pass around between pages. It is a totally different way of doing things than in the FileMaker / IWP / WebDirect world. In other words, you have to manage your sessions from the web, not from FileMaker, if you want to do things in a CWP environment.


              If this is too daunting, then perhaps WebDirect would be a better option for you? Especially if IWP sufficed for your existing load? WebDirect does offer considerably more flexibility for your interface than IWP did. And it's not deprecated, so it should be around for a while.



              • 4. Re: Using FM via PHP, wrapping my head around it



                Thanks for your input. I know I'm asking time consuming questions and it's a big help. Let me make sure, though, that I understand this well enough to get down to specifics. Say captain John Smith identifies himself on a web page. That leads to a page listing his teams. He selects to look at status of team 2. That leads to a page including a list of bowlers. He selects Susie Q to see how she's doing, which leads to a page of info about her. Each of those is a conversation between PHP & FM. Now he clicks a btn to see a page of her current pledges. PHP has to pass to FM that this is session 123, wanting a list of pledges, which are for Susie Q, when she's bowling on Team 2, of Captain John Smith's teams. (We could actually get the pledges by some linking ID# but I'm giving a hypothetical here.) PHP has to pass all those specifics. Then for FM to get to just those pledges it would go to layout Captains, find record John Smith, go to related layout Teams, find record Team 2, go to related layout Bowlers, find record Susie Q, go to related layout Pledges.


                Or FM could keep a list of current sessions and their states itself, in which case PHP could simply pass that this is Session 123 requesting pledge data. FM would look up session 123, find that that session last left off focused on John Smith/Team 2/Susie Q, and get the pledge data that goes with that. It would still have to go through all the layouts and finding to get there.


                In either case, wow, is that inefficient and convoluted compared to FM simply maintaining the session. I understand the concept of stateless and stateful systems. Both of the strategies above are ways to compensate for statelessness. I understand the web needs to be stateless because otherwise there would be millions of sessions to keep open around the web. I realize if our web page was going to have masses of sessions at a time, all fetching from FM, it would have to be stateless to not overwhelm the FM server. But in a case like ours it's unlikely there will be many people on at once. I don't know what the peak is but IWP handled it last year. There's no reason why FM couldn't be stateful, as it normally is, and keep its sessions open until either log off or some reasonable timeout, as it normally does.


                Given our timeline and the amount of change this implies I think I'm going to have to pull the plug. The only thing that could salvage this is the one thing you probably intentionally didn't address, is there a way to ping or otherwise keep a session open so that, though PHP is stateless, FM is stateful and maintains a persistent session?





                • 5. Re: Using FM via PHP, wrapping my head around it

                  If you've got a working solution, you've got to be insane to convert it to PHP just for the looks. Upgrade to WebDirect, tweak your layouts and save everyone a lot of time and money.

                  • 6. Re: Using FM via PHP, wrapping my head around it

                    But webdirect need very high spec hardware

                    • 7. Re: Using FM via PHP, wrapping my head around it

                      Tom -


                      For whatever reason, you're stuck on the idea of a "session". There are only two reasons why you would need to maintain the identity of a user from page to page:


                      1) Security (you don't want user A to see stuff only user B should see).

                      2) Convenience (once user A logs in, you don't want him to have to identify who he is or filter through other people's stuff)


                      There are plenty of CWP solutions that do not maintain sessions. Maintaining a session does not solve your problem, whatever you may think.


                      Let's look at your scenario. You want to drill down through a series of related tables. In the FileMaker scripting world, that consists of one command: Go to Related Record. But if you break it down, what it actually says is, "Find me all the records that have a foreign key equal to X, using layout Y as the context." (We'll skip over the complicating factors of "use found set" and so forth.) But this doesn't work in the context of a "session"; it's just based on local information (i.e., the user's current found set). The server just knows he's logged in; it knows nothing about where he is in the database or what records he's viewing.


                      Now, in the PHP world, you do exactly the same thing. You issue an API command that says, "Find me all records with field X equal to value Y, using layout Z as a context." You don't have a "Go to Related Record" command, but the functionality is identical. Yes, you have to use considerably more code (because there is a series of commands to be issued), but it's doing the exact same thing.


                      If you don't meet the requirement of either security or convenience, you can get by without having sessions at all. How? You simply present a list of parent records (for example, bowling team captains) and allow the user to click on the one he wants. That ID is embedded in the link, so when it drills down to the next page, you tell the PHP engine, "Find me all the Team records associated with Captain ID X". Exactly the same as Go to Related Record, just in PHP code. Similarly, every link on the Team page has an embedded ID that you can use to drill down to team members - "Find me all the Bowlers with Team ID Y".


                      You can do all this without sessions. In fact, I'd be inclined to do it this way even if I were tracking sessions, just because it's easier and faster (you can always filter the results). But it has NOTHING to do with load. NOTHING. Furthermore, the notion of a session on the web has NOTHING to do with FileMaker. Repeat: NOTHING. This has to do with the web server (either Apache or IIS). So you're completely off base here in how this works.


                      1) Request comes into the web server, basically saying, "Give me this resource" (typically, a web page).

                      2) That web page, in a CWP world, would be a PHP page, so it gets passed off to the PHP engine.

                      3) PHP engine starts parsing out the script. At some point, it hits some API code that instructs it to make a database connection to FileMaker.

                      4) The Web Publishing Engine takes that request and passes the necessary information over to FileMaker Server.

                      5) FileMaker Server performs the requested command and passes the resulting information back to the WPE.

                      6) The WPE formats the result in a way that PHP can understand, and passes it back to the PHP parser.

                      7) The PHP parser then follows whatever instructions are provided in the script to output the information.


                      The only time FileMaker is involved at all is when it's asked to serve up some data. That's it. It doesn't even know there's a client there until that happens. So no, there is no way to "ping" a web server and force it to keep the "session" open, not in a conventional HTML / PHP page (barring the use of something like AJAX). You don't need to. Every new request to the server is a completely new interaction, and the only information you would save from page to page is the bare minimum needed to uniquely identify the user.


                      There are two general rules of thumb when it comes to comparing FileMaker client applications with CWP applications:


                      1) You can do quite a bit more more with the FileMaker client than you can with CWP web pages.

                      2) CWP pages require significantly more work to program than an equivalent FileMaker app.


                      Like all rules, these have exceptions, but the web side is simply harder. Unless and until you've built up a library of PHP functions, it just takes time to work through a functional site.


                      As David mentioned, you're engaging in a large project, attempting to rewrite an existing IWP deployment in CWP. I've done it myself and it certainly can be done. But with the availability of WebDirect, and given the fact that you don't have anyone on staff who's familiar with the CWP side, I think you either need to hire someone or go the WebDirect route.


                      Just my $0.02.



                      • 8. Re: Using FM via PHP, wrapping my head around it

                        You can run your PHP based web server on a very basic set of hardware, on a Windows, Mac or even Linux OS..


                        Web Direct would never be able to offer the performance, power or the flexibility of PHP.


                        There are licensing considerations for Web Direct which may mean that you cannot offer public access to the system. You are restricted to 50 simultaneous users and in some cases one user may indeed be utilising more than one connection / license.


                        Web Direct is great for in-house operations on the intranet or for small companies whose users wish to gain access from the outside for occasional use, without the need for a FileMaker client.


                        Web Direct is also great for those who do not wish to learn web technologies and want to build something more straightforward in a shorter time scale.


                        Web Direct is not optimised for mobile devices.


                        You still need to create specific layouts that are optimised for Web Direct.


                        You can also achieve additional performance with PHP, by using a plugin that bypasses the FileMaker Web API completely.


                        If you are building a solution for an end user, they will expect the behaviour of the web access to be similar to the experience they have with current web applications, unless they are already using FileMaker.



                        • 9. Re: Using FM via PHP, wrapping my head around it

                          Yes, yes. I made similar points last week when I strongly recommended to someone that they do *not* use WebDirect. That person wanted to move the full functionality of FM Pro to WebDirect for over 50 users.


                          This is different.


                          This organization already has a working IWP solution. They just want to make cosmetic changes. For a bowling league.

                          • 10. Re: Using FM via PHP, wrapping my head around it

                            Ah... I got the impression, they were getting a web developer in anyway...


                            You're right, if there is already an IWP solution in place that works, unless they are considering other major changes, they might as well transfer it to WD, unless the user count increases their licencing costs significantly..



                            • 11. Re: Using FM via PHP, wrapping my head around it

                              n, let me tell you right off the bat:

                              * the web is NOT PHP. the web is HTML.

                              * the browsers can process HTML.

                              * the web servers deal with documents (some containing code), when it encounters something that is NOT HTML or image, it looks for a app to handle the code and returns HTML to the browser

                              * the PHP is an "app interface" (set of code commands) that allows you to communicate with a database and it "translates" the communication from and to HTML. (it does more than communicate with the database, but when you look at the FM API for PHP, it's the database)

                              * along with HTML, you will need an understanding of the CSS (and perhaps a little JavaScript).  most of a web site is the HTML and images and CSS that makes up the "look" of your web pages.

                              * add the PHP in the spots (where needed). while not necessary to know all of PHP to use the FM API for PHP, it can be helpful to understand what is happening in that code and what you insert into your pages.

                              * add Javascript if desired to make the HTML/CSS enhanced experience for your users.


                              answers to your questions:

                                   1. I hate using the FM scripts when I can accomplish the same thing with PHP, but that's me. It's perfectly acceptable to use the existing scripts with web access. It may depend on the compatibility with web (in the scriptMaker dialog, the steps should be limited to web compatible)

                                   2. "duplicating" the layouts with HTML and CSS is possible, but not so "easy", sometimes. It depends on how complex (tab panels? portals?, etc.)

                                   2B. PHP does not do the look, HTML and CSS does

                                   3, 4 & 5. PHP does have session control http://php.net/manual/en/book.session.php




                              "Web Maven since Netscape 1.1"

                              • 12. Re: Using FM via PHP, wrapping my head around it

                                “Web maven”?  


                                Tom - Beverly has laid it out more simply than I did, but she is correct. The web is a multi-layered beast, with lots of moving parts.

                                • 13. Re: Using FM via PHP, wrapping my head around it

                                  If you are serious about using PHP to write an App interface to your FileMaker solution..


                                  This is a good read.. It may scare you a bit though





                                  • 14. Re: Using FM via PHP, wrapping my head around it

                                    Nice link, Garry! If the new users stick with HTML/CSS and the FM API for PHP, then most of the hard part is done for you (PHP-wise).

                                    1 2 3 Previous Next