To trigger a script in FM from inside the web viewer, use the fmp:// url protocol.
But I must say: I think it would be bad idea to use ONLY a webviewer and recreate all FM layouts in that. The thing that makes FM FM is the tight integration between UI building tools, the db engine and ScriptMaker. If you take out one of those elements completely you will find yourself working around things that you don't really need to.
It's a technique that fascinates me for a long time:
Imagine a data-separation with formula in the main file based on fields from the data file. WV and html is only way I know so far to achieve.
I'll come back on this as soon as WV is no more limited to 72 dpi resolution.
Be aware that with WV, you always depend on webkit engines as Safari (mac) and MSIE (Win).
Please allow me to ask a question: Why would you use FileMaker if you consider generating all pages/layouts with web technologies?
Interested in hearing the rationale behind this.
1 of 1 people found this helpful
I have seen an example of this, unfortunately. I agree with Wim, if you're going to do this, why are you using FileMaker to begin with?
I would go further and actively discourage this sort of development. Solutions have legs, and tend to live on after you work on them, so a solution like this would be very difficult to maintain and not a very good return on investment. If I inherited work where the entire interface was a web viewer on every single layout, I can't say I would be happy. Just my opinion.
First of all, thank you all for answer.
Second, sorry for my bad english, wish you will understand what i will say in this post...
I want explain, why i want to make web viewer main part of my solution.
We are a small international logistic company and we have 3 offices, 1 in Moscow(Russia), 1 in China, 1 in Kazakhstan.
Our filemaker server right now is in China, and because of the China's "Great Wall" there is a big latency when our office in Russia or Kazakhstan use our system through Web Direct. When they use our system after every their move in internet browser there is a progress bar. So it become a very big problem to us and i thought that if i use web viewer in my solution it will be like a static page, not a dynamic like filemaker's layout itself.
Im fully agree with Mike Duncan, but i dont what to do in my situation.
I think you got something wrong about WebViewer:
None of your problems get solved with WebViewer anyway!
Only solution I could imagine is to reduce data-flow on the internet due to lack of internet-performance.
Though let the server do the entire performance.
I'ld recommend to do evaluation with Terminal-Server Application.
If you're familiar with any kind of remote-access' like TeamViewer or others, you know what's all about: To reduce data flow over the internet to control- and screen-datas.
You would need 1 FMP VLA-License for 3 "channels" (Moscow, China, Kasachstan).
I'll start a project with Terminal-Server in April: 5 Channels for 5 different locations with very weak internet connection. It' s gonna be a thrill with all that new experiences
I think you miss understand what a webviewer is. The webviewer is used to view web content locally in Filemaker. This content can be on the local computer or somewhere on the internet. This would slow your database a bunch if the content was located else where. You would be using a web connection to view a database that is using a web connection to show content.
Would your Lamborghini be faster on the back of a freight train.
You would be better off using a hosting firm to host your database then each branch connects to that hosting company.
Thank you all for your answers.
I decided to use PHP api or XML publishing to solve my problem, i think its a best way.
Without commenting on relevance to the OP's long-distance access problem, I'm really surprised at all the opposition here to using web viewers in place of native FileMaker layouts. It's not just a great idea, but I've thought for 20 years that it's the natural direction for FileMaker to go in. Since probably version 3 I've always wished FMP would allow straight HTML/CSS/js interface design, but tightly integrated with the rest of what the app offers. Now that web viewers allow local FMP script calls and variable declarations, we finally have that. More widespread & creative use of Web Viewers is the direction we /should/ be moving in. They're a window out of the layout mode prison.
And there are a lot of reasons to stick with developing on FileMaker, instead for web browsers, besides drag 'n' drop layout elements... I think suggesting that the Layout Mode GUI tools are the only thing that makes FileMaker a preferable platform for rapid app development than a text editor and LAMP stack is really myopic. (Do I really need to list all its other advantages?)
I think if the possibilities of generating layouts on-the-fly from text schema aren't apparent to you, you really might not be dreaming big enough (as well as overlooking some pretty incredible already-existing solutions.) Web viewer data URLS and fmp://$/ callbacks can solve a lot of common problems that FM users have complained about for a long time. I've always considered the weird limitations of the Layout Mode toolset to be one of FM's weakest points. Why, if I have identical groups of layout elements on many layouts, do I have to edit them individually on each layout to change them across the whole database? Why can't we have a horizontal portal, nest a popover, have groups of objects resize smoothly together so they don't start to overlap each other? From a user perspective, these limitations seem arbitrary and serve no purpose. There are very substantial advantages to avoiding the built-in idiosyncrasies and limitations of many native FileMaker layout objects & features with open, extensible web-viewer based elements that are nonetheless still completely contained within the FIleMaker document environment.
I don't know that it's useful to make layouts that are 100% web viewer, no sense throwing out the baby with the bathwater. But 80%? 90%? Sure. All we really need is for someone to develop a framework for easily displaying and managing interaction with web-viewer-based objects, so everybody doesn't have to keep reinventing the portal, er, wheel... Keep watching the skies... ;-)
1 of 1 people found this helpful
Not sure if the time is right yet. The idea of building FM GUI in html (WV) intrigues me for many years know.
There's already a lot of GUI stuff we do with WV:
We know of some calculation done with JS that perform much faster when processed via the Webkit than with FM natively.
Still, future changes with Webkit and WEBKIT API with mac and Win OS' are unpredictable. You could build a great GUI with WV that could break with next updates.
1 of 1 people found this helpful
I don't know that it's useful to make layouts that are 100% web viewer, no sense throwing out the baby with the bathwater. But 80%? 90%? Sure.
Many of us already use Web Viewers for lots of UI parts, here's a recent series of posts about it from us: Web Viewer Integrations Library - Soliant Consulting
But if I'd have to put a number on it then it would be perhaps 10% or less of all layout elements. Certainly not 80 or 90%.
The difference between your stance and mine is not one of unwillingness, it is one of caution. As efficientbizz states, the web viewer behavior is not always entirely predictable nor controllable. And clearly the feature was not designed to be a full UI replacement. I'm always weary of using features over and beyond what they are meant for because it means that changes made to their functionality for their main purpose may break what I use them for. And that is too big a risk for me.
… and with Themes and CSS introduced with FM 12, maybe the ground work is laid for building dynamic layouts with FM natively similar to html in the future.
Damn, wrote another exegesis... oh well...
I'm really mystified by these responses. (And, I want to say, 20 years of satisfied long-time customers, some still 15 years later reliably running databases 24/7/365 with minimal maintenance that I originally started for them in FM5. I'm not really accustomed to thinking of myself as being an "incautious" developer. My solutions have always been durable. I don't believe caution is the issue here.)
I don't really understand why some folks are more skittish about web viewers than any other part of FileMaker. Any feature can change, anything can be deprecated, but as long as the web viewer remains just that, a window into a native web rendering engine engine, the only thing about it with potential to change drastically is the FMP URL scheme. So you write neat code instead of a spaghetti tangle, abstract your separate functions into maintainable code blocks, and there's nothing that can't be updated if a technological dependency changes in the future. That's just good development practice. And HTML isn't going to cease being backwards-compatible without a LOT of advance warning.
On every platform, developers leverage technologies that may eventually change. It's a fact of life, and it's much less of a fact of life in FileMaker's standardized environment than in, say, web app development. Has there been some statement from FM that web viewers have intended limitations (as there has been with, say, the iOS SDK, or the CSS underpinnings of themes), or that they're more likely to change in a non-backward-compatible way than script triggers, or 3rd-party plugins, or the security model, or ExecuteSQL, or WebDirect, or custom menus, or design functions, or any other FileMaker feature? Have they issued a warning about data URLs and serverless FMP:// script callbacks? In that case, I'd agree with all the reluctance, that would change the entire picture.
But failing that, I'm not clear where the supposed line that limits "what they are meant for" lies, or why web viewers are more likely to change radically or break in the future than scripts, or plugins, or the security model, or WebDirect, or any other FileMaker feature. It's not like I'm recommending hacking the theme CSS or other stuff that we weren't specifically given to use as user-facing tools. I'm not saying use them for everything, but when appropriate, you don't have to be scared of them.
There are already big commercial products out there relying on heavy web viewer use, and people base commercial solutions on things I find far more hinky and un-future-proof, like plugins. I see developers out there successfully selling pricey solutions that rely on using script triggers to keep popovers open modally all over the place. Talk about using something in a way it wasn't intended. I'm nowhere near as worried about having to update a well-designed solution's FMP url schemes in a single custom function definition or script as I would be about something that. And I see things like that all the time. How many years did we use horribly confusing nested scripts with user abort off to manage nested faux-"modal" windows in FileMaker? In the grand scheme of finding unexpected uses of FileMaker features, web-viewer based layouts are not that far-flung an idea, and I'm far from the first to endorse it. Here's a cool demo that's already 4 years old: Responsive FileMaker Design & Web-Viewer Layouts (... | F ’n’ web – FileMaker ’n’ the web: lessons learned In what way you imagine that demo breaking in the future that any other FileMaker feature is immune from, I can't guess. And I saw heavy use of full-layout jQuery dashboards in a huge FileMaker solution about 6 years ago. (Which—most importantly—the client loved.) Web viewers are reliable, and as here to stay as any other FileMaker UI element is.
If you look at the long history of it, FileMaker has for the most part not updated the app in ways that broke older databases such that they couldn't easily be updated. Some of the new behaviors introduced in FM7 broke legacy scripts badly, but we dealt with it. And if we see another disruption like that, I think it's at least as likely to be in scripting features, plugin integration, the security model, script triggers, SQL integration, or some of the server technologies, as in web viewer interaction. The FM7 upgrade broke scripts and a few calculations. That happened because we used functions that they provided, in the way they were intended!
So I get all your concerns, just not why you reserve them just for web viewers and not everything about FileMaker.
So I get all your concerns, just not why you reserve them for web viewers and not everything about FileMaker.
Didn't mean to give you the impression that only web viewers fall into this category. I tend to approach web viewers with a little more caution than other FM features because for it to function correctly it has to borrow a lot from something on the outside, and something that is seemingly in perpetual flux.
In a different thread I had a similar comment about the "send email - through email client", which I consider to be more fragile than using the SMTP option. The same caution can apply to other things like plugins for instance.
I'm not saying that you are not being cautions, I'm saying that my risk appetite is different than yours. I am very much a belts-and-suspenders guy. That's just what has worked for me.