NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/sys/mac/database/917

Text File | 1992-07-26 | 8.0 KB | 172 lines

Newsgroups: comp.sys.mac.databases
Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!nntp-server.caltech.edu!news
From: [e-mail] (Mark L. Fussell)
Subject: Re: Omnis 7
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: small
Organization: California Institute of Technology, Pasadena
References: <[e-mail]>
Date: Sun, 26 Jul 1992 22:00:51 GMT
Lines: 159


Howdy again,

A quick response to Jerry Sy (well, at least it started out as a quick response
:-).

>>  15 character field names
>>    Mildly annoying, but not despicable.  Now 8 characters WOULD be
>>    despicable.

>  well, that was not really the main point.  You get 15 characters for
>  your file name (table name) and 15 characters for your field names,
>  BUT you still get 15 characters if you use the table.field method of
>  addressing a field!  had they made that 30 characters, it will make
>  more sense.  because they didn't, you make have to settel for 7 character
>  table names and field names then, now that is despicable.

Whether you use the (unique) fieldname or table.fieldname reference, you get 15
characters for the fieldname and 15 for the table.  The maximum total length
for table.fieldname references is 30, not 15.  (When version 1.1 arrives with
255 characters per name it will have over-killed this feature)


----------------------------------------------------

>>  If you want a much longer list of peeves, I'm sure I can create it.  Omnis
>>  usually makes you painfully aware of its limitations where other programs
>>  simply don't venture into an area to entice there users (i.e. 4D's
>>  lack of "Omnis lists", multi-windowing, field events, etc.).

Actually I meant "entice their developers" (with the better spelling also :-)
more than their users.

>>                                                     ...BUT if you try to
>>  convert a sophisticated Omnis application to other environments you will
>>  be in for a big shock. And Omnis will look much, much better.

>  entice users is a good description.  I find most features omnis demonstrates
>  in their demo program is IT.  that's it, what you see in the demo is what
>  you only get, nothing more, NO MAS!

Omnis's demo programs aren't even faintly close to being the best you can do
with Omnis.  Doing more requires good examples, flashes of insight, and a
thorough understanding of how Omnis does things.

Unfortunately, as I had mentioned previously, the Omnis documentation is VERY
BAD for developing advanced applications.  There are no real examples of using
the newer Omnis 7 capabilities (there are few real examples of anything),  no
examples of a well strung together high-end application (or even a major
component of such -- especially list routines), and painfully short
descriptions of the Omnis 7 commands.  Not much help to discovering what the
program can do.

Note that simple to medium level (4D's "advanced" example programs are about
medium level) user-interfaces are pretty straightforward and I assume the
documentation and example programs could get a developer there OK.

----------------------------------------------------

>  they did a good job on reports, but maybe not good enough, most of the
>  users of my program wants a report in spreadsheet format! and currently,
>  the only way to get that in omnis is to build an intermediate list first
>  and generate the report from the list , not an excruciating (sp?) work
>  around, but still a work around.

I don't know why you could not generate a spreadsheet form report without
reading data into a list first, but using a list is not an Omnis work-around.
The Omnis list is one of THE MOST IMPORTANT and powerful features of the
environment (far stronger than the 4D set for example).  Certainly using the
best features of an environment is not a work around.  Yes, the ad-hoc report
generator couldn't do all you wanted, so that is a fair strike against it.

----------------------------------------------------

>>  Again, I wouldn't recommend Omnis to everyone.  Omnis's main strengths are
>>  being able to: develop very sophisticated user-interfaces and reports; make

>  I will call it sophisticated only when it can do what hypercard can do,
>  resize window in your program (I have to write an Omnis external to do
>  this), change scripts and attributes of buttons programmatically ( now
>  I have to create say, 10 different buttons and hide / show them as necessary
>  instead of having just one button (or other objects for that matter) and
>  the ability to modify the attributes (e.g. size, location, etc) dynamically
>  in ca program), etc.  the current state of the user interface is that you
>  are either stuck with it or do excruciating work arounds.


To move and resize a window procedurally you use the command:

    OPEN windowname/leftpos/toppos/rightpos/bottompos
or    OPEN windowname/STACK
or    OPEN windowname/CENTER

with each parameter (after the '/') begin optional.  It may be a little weird
(obscure) to use the same command for "Opening" a window and for
"Moving/Resizing" a window, but the functionality is there.  You can get the
current open windows and their positions from:

    Build Open Window List

----------------------------------------------------

You are quite correct that Omnis can not create or move 'Window Objects' at
runtime.  For almost all applications this is not important (though I do agree
it can be very handy).  I do not think that Omnis is the way to create ANY user
interface and would personally choose Smalltalk for that purpose: having to
create any user-interface on demand.

Comparing a database development tool with a more general purpose language is
not very useful unless you compare it on ability and ease in doing the complete
job: building a single/multi-user relational database.  Hypercard by itself
would certainly fail at this competition.

As a relational database front-end it:
    1) Needs third-party externals to connect to SQL servers,
        and the programming interface will be weaker than Omnis's
    2) No local concept of tables and fields
        (except programmatically)
    3) Could not store the results of queries in a convenient,
       manipulable form,
    4) Has much more limited data structures
    5) Would run slower

Even focussing on UI features Hypercard has:
    1) Much poorer multi-windowing support.
    2) Lack of color window objects (except displaying PICTs)
    3) Less built-in window objects
         (requires externals for popup menus, lists, etc.)

Finally, as a development environment Omnis 7 is much stronger (but has a
stranger language).

I'm not arguing against Hypercard being better at some applications than Omnis:
Hypercard has much better control of the event loop, can create/modify window
objects on the fly, and has many useful externals designed to go with it.  But
we were discussing ability to produce high end interfaces to relational
databases, not any application.

An aside: Smalltalk would win against Omnis in many areas where Hypercard
loses, although it would still require purchasing class extensions for the
database management routines.  Other than that, I would whole-heartedly
recommend it to anyone developing many types of databases ASSUMING they have
the money (LOTS of it for Smalltalk-80 plus the database package, a normal
amount for Smalltalk/V) and the willingness to travel Smalltalk's learning
curve.

Jerry Sy seems to be comparing Omnis to an application that combines the best
of Omnis, Hypercard, and SQL (and I assume many other useful features).  I
personally wish Omnis (or something else) was Smalltalk with persistent
objects, relational capabilities, a great UI builder, and for under $1000.  I
don't think Omnis will EVER be all of that, and unfortunately don't know of any
product which currently is.  But I am constantly looking for it :-)


                                      -- Mark

Mark L. Fussell
[e-mail]