Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.databases.filemaker > #1223

Re: webviewer background image from filemaker container field

Show all headers | View raw

On Tuesday, March 24, 2009 8:24:25 PM UTC+1, d-42 wrote:
> On Mar 24, 9:35 am, Darren <darrenburgess1...@gmail.com> 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

The User wants to know if there is a way to get a transparent web viewer window.
I would like to know this as well.

Back to comp.databases.filemaker | Previous | Next | Find similar | Unroll thread

Thread

Re: webviewer background image from filemaker container field lisas4us@gmail.com - 2013-03-30 19:17 -0700

csiph-web