Re: Object-Referencing Strategies

In article <1992Sep3.172635.105_at_datani.dk>, la_at_datani.dk writes:
> ...Object-Referencing is a way (as far as I can see) to ensure that changes
> will be reflected in the whole system, and as so just what I want.
>
> ...So I want to know:
>
> 1. When is it a good idea ?. Advantages.
> - library forms???
> - for blocks
> - for fields
> - for triggers, procedures.
>
It is always a good idea to collect procedures into library forms since in v6 this is your only way to hide information about your objects. You can write procedures for validating every column used on any form, or for performing trigger actions. Then you will write procedure calls in your triggers instead of lots of pl/sql lines. To remain compatible with v7, i recommend that you collect procedures in your library rather than triggers, fields, or blocks.

If the same block is used on many forms, consider writing it as a separate form and then call it when needed. Use global fields to pass parameters between such calls.
>
> 2. Drawbacks.
>

You will be obliged to observe very strict coding and naming standards so that procedures can reference block/field objects across all forms in which they are referenced. This is beneficial in any programming system.

Programmers will have to specify the userid of the library owner when generating, that is, they will not be able to enter "SQLFORMS30 /". Perhaps this is no problem for you.

>
> 3. Experiences.
>

I felt that sqlforms generation performance was seriously reduced when many small procedures were referenced (that is, generation was much slower). This may be a local response to our database conditions, or it may be universal. One solution may be to keep forms as short as possible (fewer screens per form, more forms) to reduce your development time.

--
Dave Mausner, Senior Consultant / Datalogics Inc / Chicago IL / 312-266-4450
dlm_at_dlogics.com                                 Motto: Just show me the code