Hello from a Filemaker renegade

[Richard Gaskin]

Norman Winn wrote:

> As the person originating this thread and considering moving from 
> Filemaker to RR I am aware that I must recreate my interface and set 
> about choosing, learning an SQL type database system.
> 
> My concerns in contemplating this move are:
> 
> 1. Can I reproduce enough of my interface to satisfy my client?

Probably more so.

User interfaces are primarily event-driven, responsing to user gestures 
on controls.

FMP is pretty much limited to two events:  mouseUp on a button and 
menuPick in a menu item.

In FMP you have only one modifiable menu, so if you need a custom file 
import routine you can't put it in the File menu where a user would 
expect it, but must place it in the Scripts menu.

Rev has dozens of events to respond to, so the flexibility is almost 
mind-boggling when coming from FMP.  For example, it's quite common for 
a double-click event in a list to trigger the default action, usually a 
button in the layout.  This triggering is not possible in FMP, but is a 
trival extra to include in Rev:

    on mouseDoubleUp
      click at the loc of btn 1
    end mouseDoubleUp

Other advantages I like are the flexibility and ease of parsing using 
chunk expressions ("get word 1 of line 2 of gMyGlobalVar"), and being 
able to use true global variables rather than needing to add fields to a 
  table, and many others....

> 2.  Can I solve my speed bottlenecks? This is not unrelated to (1) as, 
> if the client sees big speed improvements here, he is likely to be 
> tolerant of interface differences. In this respect, I think the 
> possibilities look very good.

I would be surprised if you find areas where FMP's DB outperforms the 
highly-optimized MySQL engine, or its UI outperforms Rev.

And I don't know if this is now and option in FMP7, but in previous 
versions windows were not double-buffered, which gave layouts a bit of a 
clumsy effect during redraw (akin to Mac Classic dialogs, in which 
controls are drawn directly to screen one at a time rather than into a 
buffer and having the buffer copied over in one move).

Rev allows you control over double-buffering (just set the alwaysBuffer 
of a stack to true), making for a very smooth, modern-feeling redraw.


> 3. Is there anything I cannot replicate with enough effort?

I've come across nothing I can't deliver more gracefully in Rev.  Some 
things are easier than others, as it true with any system, but overall 
the balance I find with Rev is quite favorable.

I still like FMP for internal databases -- my billing system is built in 
FMP (though I'm slowly migrating portions to Rev).  FMP is a great way 
to put together workgroup solutions really quickly with minimal effort.

But for client deliverables, though I like to include FMP in our tools 
evaluation matrix at the outset of a new project, it usually gets booted 
early on because of its minimal UI flexibility.

> 4. After the initial learning curve will my productivity be greater than 
> with competing tools?

In my experience, yes.  As a true scripting language you'll get farther 
than with the confines of FMP's point-and-click "scripting", and as a 
very-high-level language you'll get more done per line than in most 
other languages.

> 5. As RR's scripting is proprietary it is most critical the company 
> stick around so my investment in time will not be lost. I cannot over 
> emphasise how important the activity and supportiveness of this list is 
> in providing reassurance.

The Rev engine was acquired by Runtime Revolution Ltd. last year, after 
having been in the market for 13 years under its former name, MetaCard. 
   With almost no marketing, MetaCard Corp. was able to keep expanding 
the engine and the number of supported platforms without difficulty, and 
with Runtime Revolution Ltd's strong marketing efforts (they just won a 
MacEddy for v2.2) there should be no reason for this growth to slow down.

Of course, if you've been in the business as long as I have you know 
that products come and go, even from big companies like Oracle and 
Sybase.  But enough people have enough invested in the engine and it has 
a sufficiently strong and well-demonstrated value proposition that I 
have confidence in it being around for many years to come.

MySQL, of course, looks like it's going to be here a very, very long time.


> The potential benefits of the effort are large. If I take on the 
> problems I have a solution that I own i.e. no runtime licences, that I 
> can sculpt in myriad fashions not available in FM. I have data/interface 
> separation. 

Amen.  De-coupling UI, logic, and data carries tremendous value, and is 
easy to do with Rev.

In a way, Rev could be said to be far closer to 4D than to FMP, as 4D 
provides a rich programming language and event-driven UIs.  But even 
then, IMNSHO comparisons favor Rev's simpler language and greater 
variety of supported platforms, not to mention the strength of relying 
on MySQL for storage and retrieval, which is fast becoming a de-facto 
standard.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com