Flasher Archive

[Previous] [Next] - [Index] [Thread Index] - [Previous in Thread] [Next in Thread]

Subject: Re: FLASH: Flash and Databases: LONG
From: Wayne Townsend
Date: Sat, 29 Jul 2000 19:55:59 +0100

Hi Matt,

Tell your client this: The real beauty of using Flash for the front
end to a data base over html is that you don't have to redraw a page
when replying to the client, and you only transmit the needed data
back and forth, not html code, which makes it faster. It's also a
better GUI for the client, because you're not redrawing "pages" all
the time. They can look through lots of data and yet have the
feeling of staying in the same place, which they like since it's less

The number of records is a matter for the CGI/database engine, not
the Flash client.

We're involved with a client who's needs are *very* similar to what
you describe. It's an extremely popular site, so they were looking
for a high-performance custom solution.

We use Mac G4/500s with WebTen (Unix Apache). The performance is
outstanding, and they are secure, and easy to set up and administrate.

For the CGI engine / Database, we use FlameThrower,
(http://www.incwell.com) which is a high-level language capable of
building just about any web app you can imagine. It has it's own
internal database structure, which makes it very fast when you have a
lot of database actions to perform. IOW, you don't have to go
outside the CGI to retrieve data. This is good to about 100,000
records in a single data set, but you can have multiple data sets.
Beyond that, you can link it to external databases, including an NT
SQL database if you were so inclined. Flame has an english-like
syntax, which makes it easy to learn and quick to develop with. It's
a mature development tool, based on SuperCard, and the SuperTalk
language, which has been in use since '88, building commercial-
quality standalone double-click desktop applications. Oh by the way,
the SuperTalk language is *ahem*, very similar to Director's *Lingo*.
Except of course that it was on the scene first and is quite a bit
more powerful today. And just to stop any flames right here, I
should point out that to those old enough to remember, our beloved
Jon Gay, the Father of Flash, has roots in Silicon Beach, the
original company that developed Supercard/ SuperTalk. So it's not
like we really come from different camps or anything.

At any rate, the Flash client can retrieve the data easily enough
from Flamethrower in real-time, and if needed, the Flame CGI can
write out text files that the Flash client can access.

If you use Flamethrower as your CGI engine, you won't have to know
much about how servers work in order to build very powerful server
apps. Flame takes care of the dirty work for you, like html headers
and such. And you won't have to spend weeks learing a cryptic

Oh yeah, Flame is a multi-threaded language, which means that it
processes multiple calls at the same time.

Now, here's how easy this is to do...

For example, lets say you have a situation where you need to pull up
an individual's contact info.

In your Flash client, you have text fields for the data, say, city,
phone number, and email address. (using this for simplicity's sake)

You will have named your fields in flash appropriately, city, phone, email.

You key for the lookup is "username". And you have a field for that.
And a "get it" button (with a play action).

You are going to make flash send the call to the Flame CGI, and then
put it into a loop to wait for a response before moving on. You can
use a simple variable to check for a response. For example:

Set variable status = 0

As you'll see below, when Flame replies, it will set status to 1, and
that's what you're waiting for.

In the next frame you do a cgi call. ie. A Load Variables action
that looks like this:

Load variables(theURL,"",vars=post)

Don't worry. You don't have to do anything else. Flash will send
all the variable on this timeline to the server. This doen't get any
easier, does it? ;)

In the next frame you set a looping label like "waitloop". Whatever.

In the next frame you do your conditional check:

If staus = 0 then goto and play "waitloop"

On the server side, you have Flame running with a handler that looks like this:

on cgiEvent
--first you parse out your lookup key:
put cgiParamValue("username") into username

--then you go get that person's info:
put card field "city" of card username into city
put card field "phone" of card username into phone
put card field "email" of card username into email

--then you send it all back to flash with the status variable updated to 1
cgiReply "status=1&city=" & city & "&phone=" & phone &
"&email=" & email

end cgiEvent

In about 2 seconds from the call, (depending on traffic), the
variables will pop into your Flash's fields, without you doing
*anything* else and the movie will go on, possibly back to your main
query point with a stop action.

I'm not kidding you, it's that straightforward and simple. Voila,
you are now a server app programmer. And you thought you were just a
"Flash Artist". ;)

Seriously, without even cracking a book, if you just typed that
script into your project script in Flamethrower, it would work. It
would take you about 30 minutes to do this whole project, Flash and

For the photos/images, you can create individual flash movies and
load them with a "Load Movie" command on top of your main Flash page
background. The advantage of setting it up this way from the
beginning is that it becomes very extensible. IOW, you can add all
kinds of stuff to what originally is just an image. ie. more images,
etc, and you can even stream quality voice with the folks pictures at
28.8 with no download. If you build it this way, you won't be locked
in, and the project can easily grow.

There you go, Matt. Hope this helps.

And for the other Flash Artists out there who think it would be
profitable for them to be able to easily write server apps that will
work exceptionally well with Flash; but they're not *programmers*,
and also don't want to dirty their hands with cryptic codeing stuff,
then Flame is for you. This is a big-boy language, that's
human-friendly, ie. it's *english language* talking to a computer.
But it sacrifices nothing in regards to performance in the process.
Best of both worlds.

G4s / Unix Apache / FlameThrower. Nothing better.

That's how our multi-user, real-time web games came to life.



>I need some help in determining the best direction to go with a forthcoming
>site. The site's functionality will include a searchable database of between
>2000 and 3000 individuals, various fields + image.
>From a design perspective Flash will give me the ability to create a dynamic
>looking interface for the company. However, Flash and Databases are two
>words I have not put together in one sentence before!
>Can anyone give me guidance as to what direction to take, what resources are
>out there etc. I have had a brief glance at Macromedia Generator and Swift
>Generator. Are these the only methods of delivery? The database exists as we
>speak in FileMaker, would this make a difference? ASP, ColdFusion. These are
>all terms I have heard but know virtually nothing about. Would people
>suggest outsourcing, or can it be learnt off my own back [everything else
>has been].
>I am not averse to doing this 'outside' of Flash if the advice is that Flash
>could not handle the amount of data and be reliable/fast in it's delivery.
>I will stop babbling now. Any response would be appreciated even if it is to
>point me in the right direction.
> Full flasher archive now available online at:
> http://www.chinwag.com/flasher/archive.shtml
>To unsubscribe or change your list settings go to
>http://www.chinwag.com/flasher or email helpatchinwag [dot] com

Wayne Townsend,
Founder, CEO, Accesson: www.AccessOn.com
Millennium Entertainment Technologies: METgames.com, LLC
waynetataccesson [dot] net, Alt: waynetatabsolute [dot] net, Studio: 760.329.9990
(US), Toll Free: 800..399.4969, Mobile: 760.902.5299 (US), WEB:
AccessOn.Net http://www.accesson.com / .net &

Full flasher archive now available online at:
To unsubscribe or change your list settings go to
http://www.chinwag.com/flasher or email helpatchinwag [dot] com

  FLASH: Flash and Databases, Matt Coyne

[Previous] [Next] - [Index] [Thread Index] - [Next in Thread] [Previous in Thread]