NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/database/oracle/1429

Text File | 1992-08-30 | 8.8 KB | 210 lines

Newsgroups: comp.databases.oracle
Path: sparky!uunet!charon.amdahl.com!pacbell.com!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!csus.edu!netcom.com!tcox
From: [e-mail] (Thomas Cox)
Subject: Regenerating SQL*Forms with CASE
Message-ID: <94gn3![e-mail]>
Date: Sun, 30 Aug 92 22:02:13 GMT
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Followup-To: comp.databases.oracle
Lines: 199

This is a LONG note.  It follows up several points various people have
made about the difficulty of re-generating a form (from SQL*Forms)
from the Oracle CASE tools.

The basic problem stated was this: a generated form may come out about
80% complete (YMMV).  You can then customize it.  But if anything in
your CASE design changes, you'll want to re-generate that form to
include the new design elements.  Woops -- your custom work just got
overwritten.

I suggested that the newer version of the Oracle CASE Generator for
forms (version 2 of the generator) was supposed to solve this, by
nondestructively re-generating the form.  This claim was met with a
certain healthy skepticism (included here):

[e-mail] writes:

>What does this 'nondestructively' mean? How generator v2 checks which
>parts have been hand-modified?

>What if the CASE logical model and hand-modifications contradict? Which
>change takes presedence? Can I specify that I want to keep this
>piece of hand-modification and replace this hand-modification with the
>changes implied by the new CASE model?

>Is the technique foolproof?

>No, I don't have a manual at hand. Neither do I wish to hear any
>marketing vaporware - I would like to hear a precise technical answer,
>if possible.

>Juhani Jaakola
>[e-mail]

Here is the answer that I (and Juhani) received from Oracle UK:

    ----begin-forwarded-message----

.From [e-mail] Thu Aug 27 08:24:23 1992
.From: "Simon Stow - - CASE Worldwide Marketing" <[e-mail]>
Subject: Customization of SQL*Forms


Steve, Anil, Tom, Juhani,

I'm sorry but I am unable to contribute directly to the NeWs group
comp.databases.oracle directly. [He agreed to my posting this for him.  --Tom]

You raise a number of interesting (to me at least) issues regarding
the generation of SQL*Forms applications using CASE*Generator for
SQL*Forms. I would like to try and provide some (helpful) answers.

Firstly, as to that horrible rumour about INP files. I too have heard
this. I agree with Steve Schow (sjs@netcom) and his liking for the INP
file. We too store forms as INP files and use RCS etc to manage them.
The latest I have heard is that there will be a readable file storage
of SQL*Forms applications.  However, exactly *how* readable that will
is not yet clear (to me at least).  It seems that, at the very least,
it will not have a format that is familiar to those of us who have,
over the years, cracked the INP file format and revel in our ability
to explain what ``**Y'' meant in a V2 INP file. This is not a "ploy to
get us to buy their CASE tools", honest. If it was I'm sure they'd
make the SQL*Forms Designer's interface totally unusable. Now they
(we?) wouldn't do that would they (we?).

Tom Cox pointed out how CASE*Generator for SQL*Forms V2 copes with
customizations made post-generation. Not unnaturally, Juhani Jaakola,
requested not to " hear any marketing vaporware - I would like to hear
a precise technical answer, if possible."

Well, I may be in marketing now, but I used to develop Oracle's CASE
products (in fact, I designed both versions of the generator). And I
do have a technical paper describing the process of regeneration in
some technical detail. If you would like a copy please send me your
address and I will put a copy in the post. (It's more than 30 pages
long so I can't fax it to you.)

[Please DON'T do this -- as a condition of posting, Simon asked me to
change the method of delivery slightly.  See the end of the note.
--Tom]

The bottom line is that regeneration does work and does preserve your
post-generation customizations; we have some success stories from real
users.

You might also like to know that the Oracle CASE team are working hard
on the development of a version of CASE*Generator for SQL*Forms to
support SQL*Forms V4. This should be available shortly after SQL*Forms
V4 itself becomes available. Continuing to manage your forms
development using CASE should therefore be your way out of the forms 3
-> forms 4 migration problem.

Anil, your use of awk to customize your forms suggests that you are
making the same customization to each form. If you are using
CASE*Generator for SQL*Forms V2 you might consider using the template
form for this. Code added to this form is automatically included by
CASE*Generator in each generated form.

Regards

    Simon Stow                   Internet:    [e-mail]
    Product Manager             UUCP:    !uk.oracle.com!sstow
    CASE Worldwide Marketing     Usenet:    uunet!oracle!sstow
    Oracle UK

    ----end-forwarded-message----

[If you want to get the 30+ page paper Simon talked about, here are
several ways to do it:

USA: call Oracle at 800-ORACLE-1 and ask for part number 52493-0192.
Non-USA: call your local Oracle office; ask for "        "  .
Can't find local office:  send paper-mail address to
    [e-mail] and I'll send you a copy via paper mail.
-- Tom]

As a followup to some more detailed questions, Simon also wrote the
following, which he also agreed to let me post here.  The plain text
is from <[e-mail]>, and Simon's comments are here
prefixed with "S> ".

    ----begin-forwarded-message----


I think CASE will be a major player in future software development, and
I think lower CASE (that is, generators) will be the most important
productivity booster. I have liked Oracle CASE products so far (even the
generator v1 - haven't seen v2 live yet), especially the smooth
integration of upper CASE - lower CASE - Oracle tools. At least the
"marketing hype" goes to the right direction.

[S> == Simon]

S>  V2 really is (no marketing hype) an enormous improvement on V1, in terms of
S>  added functionality and configurability

The hand-made customizations would be of the following classes:
- translating automatically generated english messages into finnish
  (can I accomplish this via preferences or templates or something else
  BEFORE generating my zillion forms)

S>  Yes, In v2 there is a preference (NATLNG) which allows you to specify which
S>  language (any one of 15 or so European languages eg Finnish, German,
S>  Polish) the generator is to use when generating text that the end user
S>  of the generated form will see

- customizing block synchronization
  (but aren't there preferences i.e. can I choose from a set of possible
  ways during generation?)

S>  V2 offers many more options for block synchronization including one to
S>  allow the end user of the generated form to toggle automatic querying
S>  on and off

- implementing complex logic such as arithmetical constraints or
  arithmetical dependencies

S>  V2 offers support for derived fields and columns, and constraint checking.
S>  Currently these are limited in their scope in that they can only refer
S>  to columns and fields in the current record or in records in the 'logical
S>  horizon of the current record (i.e. lookup fields via foriegn keys on
S>  the current record.)
S>  For example you can have total_price derived from the expression
S>  total_price = quanity * unit*price
S>  or say that the constraint end_date >= start_date must be applied to
S>  all inserts or updates.

I would prefer doing the abovementioned customizations via preferences
in the CASE*Generator. Are there such "preferences" in CASE*Generator?

S>  Indeed there are about 140 of them

Have you tried to classify possible customizations in order to make such
preferences? Having a rich set of such preferences should eliminate most
laborous hand-customizations.

S>  One major activity during design of the generator was to look at the
S>  various different ways that forms builders used SQL*Forms. Where
S>  possible we then offered preferences to allow the generator user
S>  to create forms in the style of their choice. In particular, there any
S>  many new preferences controlling the look and feel of generated forms.
S>  Preferences have developed into a sort of 'on-line standards manual' for
S>  forms developerd.

Sorry I don't have CASE*generator v2 manual, so I can just check it
myself. I have talked with Oracle Finland reps and I have a vague
understanding that v2 should have such "preferences".

S>  I hope some of the stuff I have sent you will help answer more questions.
S>  If not mail me again.

    ----end-forwarded-message----

That's it.  I told you it was long.  Flames to me -- leave Simon
alone! :-)
    -- Tom
--
Tom Cox      DoD #1776   '91 CB 750 Nighthawk   [e-mail]
Yeah, I have a day job.  They don't believe me any more than you do.