You might be interested in Reactor from Fusion Plugins. (Just don't
try Google-ing "fusion reactor" and expect it to show up on the first
page!)
<http://fusionplugins.com/products/reactor/>
It enables all kinds of cool "two-way" data solutions in the web viewer.
j.
On Aug 3, 2009, at 10:11 AM, Brad Lowry wrote:
Hi Tim,
I was never saying Web Viewer was the be-all-end-all. I was trying
-- off the top of my head* -- to think of uses for this new (to me)
found tool -- specifically to deflect a "why would you ever use it"
implication.
(* submission of a web form with contextually prepopulated FileMaker
data was not off the top of my head, it is a technique I have used
since 1999 and can presumably be done more elegantly with
dynamically built Web Viewer content)
With Web Viewer and content being dynamically built one layout can
be a thousand layouts. I think that is pretty cool!
[kinda like "index.php"]
That's all.
Thanks for your thoughtful response,
Brad
On Sat, Aug 1, 2009 at 5:28 PM, Tim Mansour <[email protected]>
wrote:
Brad, I'm glad that your new-found web viewer experiences are
positive, but I have some misgivings about your opinion of their
benefits. Web viewers are great for some dynamic, presentation-level
coding but they are by no means the be-all and end-all.
> 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.
And if you leave a field off a FileMaker layout, there's no way anyone
knows it's in the database apart from you. The idea is to present
appropriate information to each user, and this can be done via
numerous FM techniques (founded on access privileges).
> 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.
Which, to me, doesn't necessarily sound more attractive than editing
the FileMaker layout. But moreover there is an issue with getting
information back and forth between a web viewer and FileMaker fields:
web viewers are great for presentation but they are not designed for
data input.
One of the most successful uses I've made of web viewers was for a
client solution that involved uploading files to a server, which used
the server's Apache and PHP to publish details about the uploaded file
so that the FM client could display the upload status. Extracting HTML
from 3rd party web sites is another obvious use. But I don't believe
that using it as a central method of data interaction *within* the
FileMaker ecosystem is going to be particularly successful for you.
--
Tim Mansour <[email protected]>
Neologica Print & Promotions (ABN 63 904 335 408)
Certified FileMaker 10 Developer
159 Commonwealth Street : Surry Hills NSW 2010 : Australia
What manner of man are you that can summon up fire without flint or
tinder? / I am an enchanter. / By what name are you known? / There are
those that call me ... Tim. -- From Monty Python and the Holy Grail
--
Sincerely,
Brad
--
Jonathan Fletcher
FileMaker 9 Certified Developer
FileMaker 10 Certified Developer
Project Foreman
NewMedia Construction Co.
[email protected]
Instigator
The BB&J Network
The "Go-To Guys" for
FileMaker Development in Louisville
www.thebbandj.net
FileMaker Louisville Blog and Podcast:
www.filemakerlouisville.posterous.com
