Regenerating SQL*Forms with CASE

From: Thomas Cox <tcox_at_netcom.com>
Date: Sun, 30 Aug 92 22:02:13 GMT
Message-ID: <94gn3!-.tcox_at_netcom.com>


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):

jaakola_at_cc.helsinki.fi 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
>jaakola_at_cc.helsinki.fi

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

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

.From sstow_at_uk.oracle.com Thu Aug 27 08:24:23 1992 .From: "Simon Stow - - CASE Worldwide Marketing" <sstow_at_uk.oracle.com> 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_at_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:	sstow_at_uk.oracle.com
	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

        tcox_at_us.oracle.com 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 <jaakola_at_cc.helsinki.fi>, 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 tcox_at_netcom.netcom.com Yeah, I have a day job. They don't believe me any more than you do.
Received on Mon Aug 31 1992 - 00:02:13 CEST

Original text of this message