Re: Help with Designer 2000 modular blocks

From: Jeff T. Orwick [C] <orwick_at_cig.mot.com>
Date: 1996/03/25
Message-ID: <31576778.41C67EA6_at_cig.mot.com>#1/1

Blair Lowe wrote:
>
> Questions on use of Designer2000
>
> Does anyone know the answers to any of these questions?
>
> 20/3/96
>
> 1 Des2k "How can you implement a library form concept for blocks/pages? -
> if not possible, what would be the best alternative approach?"
> Context: Referencing an address block which can have different field
> labels and/or different structure depending on Country. NB Post-generation
> coding is not being contemplated.
>
> 2 Des2k What is the best way to implement a common block that will be
> used in many forms?
> context: E.g. a search block used as the first enterable block and
> controlling the records displayed in the rest of the form. NB
> Post-generation coding is not being contemplated.
>
> 3 Des2k What is the best way to implement fields which can have variable
> formatting depending on Country?
> Context: E.g. social security numbers. NB Post-generation coding is
> not being contemplated.
>
> --
> Computer Engineering Inc. (403) 499 5687; hw/sw/ORACLE Consulting

Questions 1 & 3

---

2 Oracle applications, manufacturing and financials, use a solutions they called "FlexFields". This is how it boils down. You have to create a "data based" form. The labels on the form are really "display only fields" of data stored within your application, with the constraints also stored in as entities as well.

Think in these terms

Some of the Entities you may need to create are:

country_address_fields

	attributes
		display sequence
		reporting sequence <-- This may have to be an Entity
		(REMEMBER: Not only do you need to consider how to dynamicly build an

entry form using entity relationships, but also consider how you're going to report it in the correct formats for each country)

	must be related to one and only one country
	may be related to many field types

field_types
	may be related to many country_address_fields
	must be related to only one label_name
	may be restricted by one or more valid_value_groups

label_name "the label that is displayed on your form"
	possible attributes
		default_max_length
		default_type (char,varchar2,number,long,etc...)
		default_required
		default_unique
		etc...
		(NOTE: allow the field_types entity to over-ride these settings)
	may be used by many field_types

valid_value_ranges
	(DESIGN this same way that Designer 2000 does.  So if only low values
are specified those are the 'valid set')
	possible attributes	
		low
		high
		description
		comment
	may be used by one or more valid_value_groups

valid_value_groups
		group name
		description
	may be used by one or more field_types
	must be the owner of one or more valid_value_ranges

See what I'm getting at? You'll need to create enough information about the fields you want in each situation, when that situation occurs, and how to validate and control entry of information in each case.

Now all you have to do is create entities to store and relate the data entered by your users to its master record.

I hope this doesn't sound too off the wall. If you have any questions send them to orwick_at_cig.mot.com <- USE THIS ADDRESS Received on Mon Mar 25 1996 - 00:00:00 CET