The Drumbeat 2000 & Macromedia Saga


Macromedia Releases More Information About UltraDev - April 8, 2000

I was pleased to see new information on MM's Web Site about UltraDev. You should check it out. There has also been a good deal of discussion on the MM UltraDev Newsgroup from people who have also been to some of Macromedia's Demos. 

Current Assessment: 

Here is my current assessment from my reviewing what is up and from scouring the Newsgroup. I think it is a fair assessment of the product (note I am not a Beta Tester). In a nutshell UD is a step forwards for Dreamweaver users and a step backwards for Drumbeat users

How DB Users can Prepare for UD - or Wait for UD 2.0
Date: Tue, 09 May 2000 20:02:10 -0400
From: Rick Curtis
Newsgroups: macromedia.ultradev

After all of the speculation it's good to see some information about
about UD. I am excited about the product it is basically what I
expected to see, a 1.0 product with some good and some not so good. The
good side is the DW side, essentially a 3.0 product with lots of good
design features. The database side is, however, a 1.0 product with a
long way to go before it matches the versatility of DB as a 3.0 product.

Here's how Matt Lerner of Macromedia Put it

"M@" wrote:

> I'm a non-programmer, so I liked Drumbeat because it was the first product
> that let me do really amazing server-side stuff.

> On the other hand, as an Elemental employee, I had a really tough time
> marketing Drumbeat and I caught a lot of flack from users because they
> couldn't round-trip their code (ie. table editing).

> So here's the thing with UltraDev for me - I can see the future here - I can
> see six months ahead when the Exchange is loaded with server behaviors that
> let me do all the stuff I could do in Drumbeat.

> Plus, UltraDev makes it easier for me to learn how the code actually works.
> So I'm learning to code - and that's a bigger skill than just using a
> product.

> When Dreamweaver came out, a lot of people started with it by using
> drag-and-drop view. But eventually, they looked at the HTML and JavaScript
> it generated, and they learned to get into the code. UltraDev is built on
> top of Dreamweaver and works the same way.

> To answer your question: I believe that UltraDev will be everything that
> Drumbeat was and more.


So what does that mean for Drumbeat Users? I think there are really two
groups of DB users those who code and those who don't. I fall into the
latter camp. I am a professional writer, in essence a content creator,
not a programmer. I went with DB because it gave me access to database
driven content sites and e-commerce without me learning how to write ASP
or Javascript code (And, actually, I don't really have the time or
inclination to learn how to code).

From what I see of UD, the first release of the program will provide
some of what DB with database connectivity but not all the features
(like e-commerce). Combined with this is a much slicker design-end (the
mature DW side). As Matt says, 6 months down the road enough stuff will
hopefully be written as extensions and E-commerce components that UD
will start to be on par with DB. 

I don't really expect to see UD get up to DB's database level 'til
release 1.5 (if there is such a thing) or 2.0. The first version lacks a
"global recordset object" (as I understand it from the posts so far).
You can create a global connection to a database that is reusable across
pages but you have to create a query on each page rather than dragging a
predefined Smart Element over as you can see from the responses below.

>You have to create the query each time you want to put it on a page. There
>are no site-wide recordsets - FROM JS
>You will be able to copy and paste recordsets across pages so you wont have >to go through the steps of recreating them on each

It lacks a tool like the DataForm Wizard to generate commonly needed
database pages. The other thing is that all the database connection code
lives in each page. From what I know (correct me if I'm wrong) doing it
this way instead of separate include files means passing a lot more code
back and forth versus an include file that will get cached after it's
been pulled up once.

Boy, if you are building a big site with the same database connections
then it means a lot of repetitive work and not the most efficient server
utilization. Not exactly an enterprise-strength approach. Here we are
seeing the inevitable trade-offs of architecture differences. UD is DW
on steroids but the muscles aren't all the way pumped up yet. The heart
of UD is still a design-based tool with immature database stuff. DB was
built from the ground up as a database-development tool (even with all
its faults) with 3 versions to get it right. There is a clear difference
between the two products right now.

My recommendation for DB non-programmers, like myself. LEARN SQL. For
any database app it is much better to move all of the logic and
processing up into the database end of things rather than in Javascript
of Vbscript on the actual web page. This becomes EVEN MORE CRITICAL with
UD. Think about it, if you need to make a change in some database
connection it won't be just changing the underlying query like you did
in DB and having all the objects that refer to that query still run. If
you make a significant change in UD (and your SQL code is on the page)
you'll have to change it ON EVERY PAGE. So, learn SQL. If you are using
Access 97, upsize to Access 2000 and start running MDE or go straight to
SQL 7 and learn how to write stored procedures. Otherwise go to another
enterprise level database. Develop as much code as you can in stored
procedures and then just call the stored procedures from UD. Now when
you have to make a change, UD will never know about it. It will still
call the same stored procedure with whatever new changes you made to the

As others have said learning ASP is going to be a good idea (no I am NOT
looking forward to it), at least until enough 3rd party exntensions out
there to shield us non-programmers from having to write code. I expect
the second release of UD will start to iron of lot of these things out
and create something that is a bit more object-oriented and
enterprise-ready in terms of database connectivity.