Hello from a Filemaker renegade
ambassador at fourthworld.com
Sun Apr 11 20:55:27 CDT 2004
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
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:
click at the loc of btn 1
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
> 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
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
Fourth World Media Corporation
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the use-livecode