Re: webviewer background image from filemaker container field
- From: d-42 <db.porsche@xxxxxxxxx>
- Date: Tue, 24 Mar 2009 12:24:25 -0700 (PDT)
On Mar 24, 9:35 am, Darren <darrenburgess1...@xxxxxxxxx> wrote:
A agree that using a webviewer may seem to be perhaps overkill when a
calc field could do the job.
This is why I am using a webviewer
1. I want to learn how to use the viewer to display data
Ok. I can't fault that.
2. using a webviewer to display data forgoes the necessity of
creating a field.
Ok. But that's kind of like poking your eyes out to save money on
contact lenses; and then hiring someone to escort you around because
you are now blind.
3. I like the elegance and simplicity of using the interface/layout
to create the information.
It is not elegant or simple the moment you factor in how a webviewer
actually works.
On Windows, for example, with FM9 (I haven't re-tested with FM10 yet),
it uses the built in Trident rendering engine for the webviewer, which
in FM9 couldn't support more than several hundred characters in the
URI, so when you pass a data: URI, it writes out a temporary file to
the system temp folder (always, regardless of how much data you pass
it), and then passes it to the trident engine to render, and then
passes the result back to FM to display.
So, every time it updates the display of the field, it exports a
file...and so on. Its completely ridiculous. On OSX, it uses safari
which doesn't have URI limitation so low, so at least it doesn't write
out a temporary file, but again, its completely ridiculous to call
Safari to perform and display simple text concatenation.
In nearly any situation, the webviewer is the most expensive option.
In MANY cases its well worth it, because you can get precisely the
layout and format you want. But it was designed to let you embed web
pages in filemaker. That's it. Resourceful developers have used it to
build and embed web pages on the fly to achieve dynamic data display
that simply wasn't previously possible (and I fully support, and even
do it myself) but its important to really understand the big picture,
including how it works.
I have been listening to the filemakertalk podcast and the suggestion
was that webviewers save on application overhead by keeping interface
info (like a record count) out of the schema of the database.
There's never a shortage of lousy advice on the internet.
And the quality of advice in books and formal filemaker education is
pretty hit and miss too in my opinion. Some of it is really good...
some of it is just awful.
Clearly, it may be debatable how much over head a field such as a
record count really adds to database. Probably not much, and I can
see the value of thinking in terms of reducing the number of fields in
the tables.
No. There is no value in reducing the number of UNSTORED CALCULATION
fields, except to the extent that it reduces a bit of filemaker UI
clutter.
Unstored calculations add essentially NO OVERHEAD to the database.
They are kind of ugly in terms of cluttering up your schema. Most good
filemaker developers use naming conventions to address this... my
unstored calcs all start with zc_, my summary fields are zs_, zg_ for
globals, etc.
This sticks them at the bottom of the list out of the way, and
immediately identifies them as unstored calcs / sumary fields.
Fields that exist strictly for UI purposes like filter pivots, etc are
also named with a convention.
Let me say it again: An unstored calculation creates virtually no
overhead. It doesn't create and allocate storage for a field for every
record in the database. Its just a calculation definition ...its
really no different than a custom function scoped to a particular
table occurance in the relationship graph.
Doing contortions to reduce schema clutter in filemaker is demented.
As a SQL pro coming into Filemaker, it took me a while to come to
grips with filemaker's way of doing things too, especially coming to
grips with things like schema clutter.
What you should do is come the the realization that unstored
calculations at the 'database theory' level aren't really part of the
database table as it would be defined in another database system. They
don't affect normalization. They aren't adding overhead. They aren't
even evaluated until they are explicitly referenced.
I've advocated in the past that FM change the UI, to separate the
actual "real database schema fields" from the unstored clutter defined
on them (including globals, summaries, and unstored calculations).
This would let SQL guys from the wider world be more comfortable with
Filemaker... they wouldn't feel like they were bloating their database
with extraneous UI fields. But in reality, that's the only benefit...
making SQL guys more comfortable. Its just as easy for us SQL guys to
adapt to Filemaker and understand that unstored calculations, globals,
and summaries really aren't part of the database schema in the
'traditional sense', anyway. And there appearance in filemaker as part
of the 'table' defnition is really just Filemaker's UI.
-regards,
Dave
.
- References:
- Prev by Date: Re: webviewer background image from filemaker container field
- Next by Date: Re: Creating Drawings from Record Data.
- Previous by thread: Re: webviewer background image from filemaker container field
- Next by thread: Itunes 8
- Index(es):
Relevant Pages
|
