I have a "Member" object. New members register with a registration form that is only used for a first time registration. This registration form collects only a small portion of the data that is allowed after registration. This is to keep the initial amount of information the new member has to enter to a minimum.
Once someone has become a member, they can add much more personal info to the database in the way of a tabbed form that has multiple objects on it. One of those tabs (for another business object) is called "ContactInfo". Here the member can put in email addresses, home page urls, phone #'s, and more. This ContactInfo business object is owned by (child relationship) the Member object and multiple objects are not allowed. Since the new member needs some way to create the new information in the ContactInfo object, I have the "Add New" button checked in the form presentation for this referred attribute. So far, everything is working great, and this newly registered member adds their contact info to the form. When they hit save, all is well.
Here's the problem...when a member is in the edit mode of the tabbed form, it always allows them to "Add New" even if they have already added this information previously. If a member decides to add another instance of this information, the program readily accepts it. I want to limit the input of this information to a one time occurrence, which I thought the parent-child relationship would accomplish when not allowing multiples. It would be nice to have the "Add New" button show up only if the instance of that object has not been created yet. Does what I'm describing require a rule, or process to accomplish, or can it be done another way? Thanks.
Need Help with
-
aware_support
- Posts: 7525
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
The easiest way to accomplish this would be to remove the "Add New" button from the form in the Presentation options for reference and define a process that would add a new ContactInfo to the Member object. The process would take Member as a parameter and have one rule only:
CREATE ContactInfo WITH ContactInfo.Member = Member
Then define an operation to the form of the Member object that would start the above process and name it something like "Add Contact Info". When defining an operation you will need to specify its applicability condition - that is, the operation will only be applicable if ContactInfo is not already defined. The applicability condition will look like this:
Member.ContactInfo IS UNDEFINED
As a result the user will see a hyperlink above the form that will add contact info only when the contact info is not already defined.
By the way, since ContactInfo is really an integral part of the Member object is it really necessary to have it as a separate object? It could be part of the Member object and defined on a separate tab on the Member object form.
Best Regards
CREATE ContactInfo WITH ContactInfo.Member = Member
Then define an operation to the form of the Member object that would start the above process and name it something like "Add Contact Info". When defining an operation you will need to specify its applicability condition - that is, the operation will only be applicable if ContactInfo is not already defined. The applicability condition will look like this:
Member.ContactInfo IS UNDEFINED
As a result the user will see a hyperlink above the form that will add contact info only when the contact info is not already defined.
By the way, since ContactInfo is really an integral part of the Member object is it really necessary to have it as a separate object? It could be part of the Member object and defined on a separate tab on the Member object form.
Best Regards
Aware IM Support Team
Your last comment about why separate the contact info into a different object really set a light off in my head. You are absoutely right. I guess I was just trying to keep the number of attributes in Member down, but the question is..."why should I"?
I feel pretty dumb now. I have 3 objects I can combine under member and just used tabbed forms to control the input. This will solve a lot of layout issues I was having with reference attributes. Oh well...live and learn. I'm pretty new to database schema, so bear with me.
I feel pretty dumb now. I have 3 objects I can combine under member and just used tabbed forms to control the input. This will solve a lot of layout issues I was having with reference attributes. Oh well...live and learn. I'm pretty new to database schema, so bear with me.
Now I remember why I set up contact info and other member information in separate objects. I went back and combined all the other objects into the one "member" object. In other words, I deleted the other objects and put all their attributes under member. I have set up the tabbed forms for both views and edits. Remember, the only informatin I require out of all this is the initial "personal" info. Now, when a member goes to edit, or add additional inforamtion, it wants them to put in all "required" attributes from the other forms as well.
I want this to work so that a member does not have to enter data from for each tabbed form, but there will be certain required attributes if they use any one particular tabbed form. I even made separate forms for what I use to present as tabbed forms in the edit mode, and it still wants the required attributes of another form. I thought about changing the attributes so that nothing was required, but that would present possible error conditions in other areas where calculations are required, so I really need certain attributes to be required.
Any suggestions on the direction I should take to get the edit functions to work the way I presented above?
I want this to work so that a member does not have to enter data from for each tabbed form, but there will be certain required attributes if they use any one particular tabbed form. I even made separate forms for what I use to present as tabbed forms in the edit mode, and it still wants the required attributes of another form. I thought about changing the attributes so that nothing was required, but that would present possible error conditions in other areas where calculations are required, so I really need certain attributes to be required.
Any suggestions on the direction I should take to get the edit functions to work the way I presented above?
-
aware_support
- Posts: 7525
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
Well, an attribute should be marked as "required" only if an object cannot live without the value of the attribute being provided. If, like in your case, it is sometimes possible to have the value as undefined and in other cases this value must be defined, then you should really untick the "required" checkbox and provide rules that specify conditions when the value must be provided.
A rule that checks that the value is defined looks like this:
If Member.Name IS UNDEFINED AND ... THEN
REPORT ERROR 'Name must be defined'
The "If" part of the rule should specify additional conditions specific to your case.
Sometimes it may be beneficial to introduce "State" of the object, so that the object can move from state to state and there are certain rules that the object obeys in each state. Don't know if it helps in your case.
Anyway if you are having problems with this tell us when specifically certain attributes need to be provided and we can recommend a specific solution.
A rule that checks that the value is defined looks like this:
If Member.Name IS UNDEFINED AND ... THEN
REPORT ERROR 'Name must be defined'
The "If" part of the rule should specify additional conditions specific to your case.
Sometimes it may be beneficial to introduce "State" of the object, so that the object can move from state to state and there are certain rules that the object obeys in each state. Don't know if it helps in your case.
Anyway if you are having problems with this tell us when specifically certain attributes need to be provided and we can recommend a specific solution.
Aware IM Support Team