Thank you so much Miki! I have never been so happy to be wrong!
Okay, I am going to make another bold statement ready to be wrong: Why isn't this ability clearly and prominently part of the FileMaker Pro [Advanced] Help for "Web Viewer Setup dialog box" or "Defining a custom web address" or especially in "About URL encoding in web viewers". Of course, I am grateful (as always) for the existence of this list and for Miki's response, but even if I overlooked it *someplace* it shouldn't be so hard to find and should be clearly linked to by one of the help topics above. (And of course, I am interested in any *official* source and expanded explanation of this technique if you, Miki, or anyone else knows one.) Knowing to start the text with "data:text/html" is non-trivial (at least to me) and the power of this is immense. As to your point that many "don't see the sense of the work involved in HTML when FileMaker provides adequate tools", it is true that many things that one can do with HTML you can do with FileMaker. Yet I feel this is significant for the following reasons: 1. It is *always* better to have more options to handle a problem than fewer. 2. Personally, I am facil enough with HTML for it not to be much work at all. (I presume others are too.) 3. HTML is ubiquitous and univeral enough so that one can often interact with vendors, services, data and so on, elegantly and without having to jump through hoops to "make it work" with (relatively) esoteric FileMaker. (note: by 'HTML' I mean HTML and attending Web Viewer supported web technologies) 4. If a website already exists for some of the Client's data, why work so hard to bring all that data into FileMaker, when instead you can use (or expand) the already paid for web interface. (This is where FileMaker Inc touts FileMaker as "work group" software, and if "Corporate" is using Web Technologies and this project is for a work group, then leveraging elegantly existing web data enhances the choice of using FileMaker for the workgroup project and writing hours of code and demanding alternate access to corporate data [especially write access] would be frowned upon to say the least.) Indeed, the example in my original post of Posting a Web Form to a Vendor where the Web Form is composed dynamically with FileMaker data is a clear improvement on other FileMaker tools. (Assuming I can do that, I presume so.) For Another Example: As complete as FileMaker privileges are, it is often a great deal of bother to set a lot of fields as readonly for this group, totally obscured for others, and editable for others. With HTML you can easily write the HTML for the readonly and totally obscured options (and have it in a nice clean "preview" style version of the data for all) with a Web Viewer, and the only thing you have to manage is who has access to the Edit Layout and who doesn't. Further, one of the things that security experts will tell you is to not even let the potential hacker know there is something to hack. When you make a field totally obscured on a FileMaker layout then there is incentive for someone to find that value out "What the bleep is Miki's Salary!?!?". With HTML there is no way the end user knows they are being denied certain data. Moreover, you could load the HTML via a Custom Function. Then deploy. Then the client says they want this, that and the other changes made --- edit the Custom HTML Function and overwrite that code and the layout is changed *programatically* -- if you have someone on the Client's Team that you trust to execute the Custom Function overload, then you can handle it via email. Of course, this whole tangent of FileMaker providing "adequate tools" so as not to use the Web Viewer in this way is a tautology since Web Viewer *is* a FileMaker too!!! FileMaker is the bomb! (That's why I am on this list.) But FileMaker is the bomb! in part because of tools like the Web Viewer and it is nice to have one more alternative for solving such situations. Two days; Two monumental enhancements to my FileMaker life!... I gotta spend more time on this list! Thanks again. Brad On Fri, Jul 31, 2009 at 1:33 PM, Miki Eff <[email protected]> wrote: > Hi Brad, > > Yes, you can make the webviewer display html data that's generated on the > fly by filemaker. You can even you a Let statement to define all the fields > that are referenced in your html, with all the filemaker tools. All you need > in the webviewer calculation window is valid html. > > "data:text/html,<html> > <head> > </head> > <body>YOUR FIELD STUFF > </body> > </html>" > > With CSS and a good sense on XML generation with your data, the > possibilities are large. Of course there are many FM developers that don't > see the sense of the work involved in HTML when Filemaker provides adequate > tools. > > Hope this is helpful. > > > > On Fri, Jul 31, 2009 at 7:23 PM, Brad Lowry <[email protected]> wrote: > >> Hi All again, >> >> Since I got such a great response from my last WishList I am going to post >> another. >> >> Again, I hope that this is possible and that I am just ignorant of how to >> use the WebViewer or ignorant of an Elegant Workaround or even an inelegant >> Kludge. >> >> WishList: be able to point a WebViewer window to the content of a field >> and have its content render as html. >> >> I think it would be useful even if I just wanted to use HTML's tools to >> display a bunch of data as HTML formatted text (1. Which values and the >> manner in which I display the data is more able to be dynamically altered >> without any Layout changes. 2. It allows separation of Code and Display at a >> "middle tier" between the data and the layout.) >> >> Further, it could get really fancy. >> >> I could have a Web Form built within a text field by script. I can build >> it so that many, many data fields autopopulated. I can have certain values >> as html hidden fields (business rules say include that data in the form, but >> you don't want the end user to know it (SS#, TaxID, Chart Number, Diagnosis >> Code). And I can limit selections in drop-downs based on User Access >> Privileges. Then have the Submit button send it off to any B-to-B vendor, or >> service, or billing entity or... Another great advantage is that I can save >> the html of that submitted form in its entirity to a table of Submitted >> Forms as a logging mechanism. >> >> As it is now the only Kludge I can think to use is the very FM6-ish: Write >> the file to the desktop (or other local folder) and launch it with your >> browser. >> >> (Indeed, I did just this in FM6 with great effect. Some sites have gotten >> sophisticated and won't accept a form submission from an "outside source", >> but when I contacted the web guy at the target site and explained my purpose >> [and that my client was a really good customer of theirs] we agreed on >> another Hidden value I could pass in the form that would expire every three >> months that would allow an exception to that block.) >> >> Of course, while FileMaker is at it, they should add the ability to open a >> local (non-served) html file. However, this is only as an obvious >> enhancement between only served files and field content -- if I could render >> field content I can't think of a good use of opening local files. >> >> Just my two cents... >> >> Thanks for any replies. >> -- >> Sincerely, >> Brad >> > > -- Sincerely, Brad
