How to programatically set an attribute's Presentation Label

[tkilshaw]

I need a way to programatically set an attribute's Presentation Label.

Consider this scenario:

I have a set of up to 12 checkbox attributes that represent 12 stages in a sales process.

One business will define these as:

1. Meet and Greet
2. Product Presentation
3. etc

Another business may use completely different names for the stages of their sales process.

If <<tags>> were allowed in an attribute's Presentation Label that would solve my problem.

Thanks,

Terry

[aware_support]

Terry,

you cannot set these programmatically but you can define different forms for a business object where you will define different labels and/or hide attributes if neccessary. You will then show different forms to different users.

If this difference has anything to do with access levels of different users, then you can specify the appropriate access level when defining a form. If the difference has something to do with particular users (i.e. difference in their attribute values) then you will need to define a process that will check these values and display an appropriate form.

Best Regards

[tkilshaw]

If you look at my requirements they are for users to be able to change things themselves.

I don't know at config time what they will want.

Terry

[aware_support2]

Terry,

You can do the following:

1. Define object ProcessLifecycle with text attributes Step1, Step2 … Step12

2. Add the following rule to an initialisation process that will run once when the applications is first started on the client's computer. The rule will create the only instance of object ProcessLifecycle in the system:

If NOT (EXISTS ProcessLifecycle) Then
CREATE ProcessLifecycle WITH ProcessLifecycle.Step1 = 'Meet and Greet', ProcessLifecycle.Step2 = 'Product Presentation', ...

3. Add a menu item for the users to be able to edit ProcessLifecycle. The item will start a process with the following rules:

FIND ALL ProcessLifecycle
VIEW ProcessLifecycle

4. Configure object ProcessStep with the following attributes: Name (text, calculated), Completed (Yes/No, default: No), StepOrder (number, calculated)

5. Add multiple-allowed attribute Steps of type ProcessStep to object Process where Process is the owner of ProcessStep with matching attribute Process on object ProcessStep. In the presentation for attribute Steps allow Inline Editing and display attributes Name and Completed sorted by StepOrder.

6. Add the following (multi-action) rule to object Process:

If Process.Steps IS UNDEFINED Then
FIND ALL ProcessLifecycle
CREATE ProcessStep WITH ProcessStep.Process = Process, ProcessStep.Name = ProcessLifecycle.Step1, ProcessStep.StepOrder = 1
CREATE ProcessStep WITH ProcessStep.Process = Process, ProcessStep.Name = ProcessLifecycle.Step2, ProcessStep.StepOrder = 2
...

At run-time the user will see all steps in a table for attribute Steps on the Process form and will be able to tick the Completed box to indicate the completion of a step.

-----

You can add more flexibility to this design by allowing the users full control over the list of lifecycle steps, not just the step names:

1a. Configure object ProcessLifecycleStep with attributes Name (text), StepOrder (number).

2a. Get rid of object ProcessLifecycle - it is no longer needed.

3a. Change the menu item for management of process lifecycles to run a query that finds all ProcessLifecycleStep instances sorted by ProcessLifecycleStep.StepOrder. Add a menu item to add new ProcessLifecycleStep. These two menu items should allow the users to add/edit/delete lifecycle steps.

4a. The initialisation process will be:

If NOT (EXISTS ProcessLifecycleStep) Then
CREATE ProcessLifecycleStep WITH ProcessLifecycleStep.ProcessLifecycle = ProcessLifecycle, Name = 'Meet and Greet', StepOrder = 1
CREATE ProcessLifecycleStep WITH ProcessLifecycleStep.ProcessLifecycle = ProcessLifecycle, Name = 'Product Presentation', StepOrder = 2
...

5a. The rule on Process will be:

If Process.Steps IS UNDEFINED Then
FIND ALL ProcessLifecycleStep
CREATE ProcessStep FOR EACH ProcessLifecycleStep WITH ProcessStep.Process = Process, ProcessStep.Name = ProcessLifecycleStep.Name, ProcessStep.StepOrder = ProcessLifecycleStep.StepOrder


Hope that one of these two options will help you achieve what you want. Let me know if you need any clarifications.

[tkilshaw]

Thanks a lot for your response. I really appreciate it.

I'm trying to implement the second version of your solution but have a hit a couple of snags.

Step 2a) gets rid of ProcessLifecycle but step 4a) says to create instances of it!

Step 3a) Says: "Add a menu item to add new ProcessLifecycleStep. These two menu items should allow the users to add/edit/delete lifecycle steps."

I presume that means add a menu item to a Visual Perspective? That's easy.

But I can't see a way to allow users to add steps from the auto-genrated forms. Edit and Delete are options but not add.

I'm also a bit confused as to how much of the first version is kept or replaced.

Sounds hopeful though.

Terry

[tkilshaw]

On further reflection I think that version 1 will work better for my purposes.

However, in software design its often a symptom of deeper problems when you end up jumping through hoops to do what should be simple.

Basically all that I need is a way to set field labels programatically. (There's that word again!)

If that is possible all I have to do is have a set of fields that the user can edit. Those fields will hold the labels that are displayed, one for each checkbox. And if Aware allowed tags in the Presentation dialog Label field then I use:

<<Account.Stage1Label>>

And that's it!

There are other places in the system where tag processing thing is done, Presentations and others.

If the tag allowed for calling functions, or was actually a rule set, then you could also solve a large part of the internationalization/localization problem.

Suppose SystemSettings had a Language attribute that took a 2 character ISO language code.

Suppose there to be a business object called I18N, with a Key attribute and one attribute for each supported language. Example:

Key EN FR OZ
-------------------------------------
greet Hello! Salut! G'day!

Suppose there is a function GETLOCALSTRING. This could be used in the tag like:

<<GETLOCALSTRING( "greet" )>>

It would look up SystemSettings.Language and use that to find the correct string to for the label.

Anyway, I think that some kind of way to determine labels programatically is essential, and soonish if possible.

thanks,

Terry

[tkilshaw]

Here is my version of step 6 of your first suggestion. THis ishappening as a rule of Account:

If Account.SalesProgress IS UNDEFINED Then
FIND ALL ProgressLabelHolder
CREATE ProgressStage WITH ProgressStage.Account=Account,ProgressStage.Name=ProgressLabelHolder.Stage1,ProgressStage.StageNumber=1
CREATE ProgressStage WITH ProgressStage.Account=Account,ProgressStage.Name=ProgressLabelHolder.Stage2,ProgressStage.StageNumber=2

This code does not appear to get called. No ProgressStage objects are ever created. None are visible in the newly created Account or just searching for them.

I have followed all the steps suggested closely.

If I understand this properly, the IS UNDEFINED should force the code to be called before the Account form is displayed when an Account is created. But it doesn't.

I went to the Advanced tab to try to set the rule explicitly as in initializtion rule, but the relevant radio buttons were greyed out and unresponsive.

Terry

[aware_support2]

Terry,

> Step 2a) gets rid of ProcessLifecycle but step 4a) says to create instances of it!
My mistake - 'ProcessLifecycleStep.ProcessLifecycle = ProcessLifecycle' bit should not be in the rule, so the rule should look like this:

If NOT (EXISTS ProcessLifecycleStep) Then
CREATE ProcessLifecycleStep WITH Name = 'Meet and Greet', StepOrder = 1
CREATE ProcessLifecycleStep WITH Name = 'Product Presentation', StepOrder = 2

> But I can't see a way to allow users to add steps from the auto-genrated forms. Edit and Delete are options but not add.
To allow the users to add steps on the Process form, tick 'Generate "Add New Item" button' above the 'Operation with items' table on the presentation dialog for attribute Process.Steps.

> This code does not appear to get called. No ProgressStage objects are ever created. None are visible in the newly created Account or just searching for them.
This happens because the software is a little too strict at the moment and disallows this rule during object initialisation. We are going to lift this restriction within the next few days. We will post a message to this topic to let you know when the software update is available. In the meantime, please continue with the scenario without any changes. Even though no ProgressStage instances are created when the Account form is first displayed, they will be created once you click Create button to create the Account instance. You can check this with the current version of the software.


As for allowing the users to arbitrarily change attribute labels (whether implemented programmatically or otherwise), it may have very undesirable side effects. Consider the following scenario. The user named his progress stage labels as follows:

1. Meet and Greet
2. Product Presentation

and then proceeded to create a number of Account instances where he ticked the boxes for the first two attributes as appropriate to indicate the completion of the first two stages (let's suppose the other ten attributes reserved for stages remain unused). Some time later he returned to the labels list and introduced a new stage:

1. Meet and Greet
2. Show Price List
3. Product Presentation

and then proceeded to create new Process instances. The trouble is that for the existing Account instances the attribute for Stage 2 now shows label 'Show Price List' whereas previously it showed 'Product Presentation' - and that was displayed when the user indicated the completion of the old Stage 2. In other words the meaning of the attribute has now changed rendering the older data, entered when there was a different set of labels, inaccurate.

A safe solution for a scenario where the users need to be able to dynamically change stage names would be to let them maintain a list of child objects for Account object. They can change the name of each stage as the value of attribute ProgressStage.StageName, but not as a label of any attribute. That is what the two options suggested earlier are all about. In those scenarios each new Account instance receives its own list of stages according to the current set of stages as entered in the master object (or the master list). If, at a later stage, the user changes the master list, none of the existing Process instances would be affected.

I still feel the second option would be preferable because it allows the user to maintain the master set of stages as a list where he can change the number of stages as well as their order. With the first option the user is confined to a fixed number of attributes in the master object. I will rephrase the steps for the second option using your new object names and without references to the first option to avoid any potential confusion.

1. Configure object MasterProgressStage with attributes StageName (text), StageNumber (number).

2. Configure a query to find all MasterProgressStage instances sorted by MasterProgressStage.StageNumber. Allow operations Edit and Delete for the query.

3. Add a menu item (this is done in the Visual Perspective as you noted) to run the query configured in the previous step. Add another menu item to create new object MasterProgressStage. These two menu items should allow the users to manage (add/edit/delete) master progress stages.

4. Add the following rule to an initialisation process that will run once when the applications is first started on the client's computer. The rule will create an initial set of master progress stages for the user.

If NOT (EXISTS MasterProgressStage) Then
CREATE MasterProgressStage WITH MasterProgressStage.StageName = 'Meet and Greet', StageNumber = 1
CREATE MasterProgressStage WITH MasterProgressStage.StageName = 'Product Presentation', StageNumber = 2
...

5. Configure object ProgressStage with the following attributes: StageName (text), Completed (Yes/No, default: No), StageNumber (number)

6. Add multiple-allowed attribute SalesProgress of type ProgressStage to object Account where Account is the owner of ProgressStage with matching attribute Account on object ProgressStage. In the presentation for attribute SalesProgress allow Inline Editing and display attributes StageName and Completed sorted by StageNumber.

7. Add the following (multi-action) rule to object Account:

If Account.SalesProgress IS UNDEFINED Then
FIND ALL MasterProgressStage
CREATE ProgressStage FOR EACH MasterProgressStage WITH ProgressStage.Account = Account, ProgressStage.StageName = MasterProgressStage.StageName, ProgressStage.StageNumber = MasterProgressStage.StageNumber

[tkilshaw]

I did not explain my requirements properly.

The stages will be setup once for any given installation. That will be done by an admistrator and the labels will never be changed by users. All users will, and must, have the same set of labels. Administrators will not have access to the Aware Configurator.

Hence your first solution is OK.

I also continue to claim that computed labels are a necessity, and would solve of all of my problems, and have saved me two days of headbanging - so far.

Please read on.

I am experiencing further problems with the first suggested approach. I created a ProgressLabels object that has 12 attributes labelled Stage01..Stage12.

I created a Process called Init_Admin with a rule, InitProgressLabels, that is called from the Administrator Visual Perspective as its initialization process.

If NOT(EXISTS ProgressLabels) Then
CREATE ProgressLabels WITH ProgressLabels.Stage01='Meet and Greet',...

That all works well.

I have a ProgressStage object with attributes StageNumber (Number), Name (PlainText) and Completed (Yes/No), and an Account attribute(reference back to the owning Account object. ProgressStage is owned by Account.

Account has a rule:

If Account.SalesProgress IS UNDEFINED Then
FIND ALL ProgressLabels
CREATE ProgressStage WITH ProgressStage.Account=Account,ProgressStage.Name=ProgressLabels.Stage01,ProgressStage.StageNumber=1....

that creates 12 ProgressStages.

Starting with no data and logging into to the admin account, I use the generic UI to create an Account object. I add a Main Prospect with a first and last name, because an Account minimally must have one.

The new Account form does not show the list of stages.

When I click the form's Create button the screen redraws but no "Account Object has been created" message is shown and the list of stages is still not shown.

If I click the Create button again the screen redraws and an "Account Object has been created" message is shown but the list of stages is still not shown.

Using the generic admin UI I get a list of accounts. The new account is in it. But if I try this after just once click on the Account form's Create button the new account is not shown in the list, presumably because it was not created.

Using the Edit button on the list of Accounts to go to the Account's form I see that the list of stages is shown, but the Completed attributes are displayed as a column of popup menus with three values: empty, Yes and No, and not as checkboxes, as expected.

I can send you my code if you want to see this.

I'd greatly prefer the simple ability to put a tag into a label field. That would solve all of these problems, from my point of view. But I realise that may not be an option, from your point of view.

I need to have the stages displayed when the Account's form is first displayed. In the short term I could live with having to click the Create button once before the stages are shown.

But we a losing heart here. My work was undertaken proof of concept that Aware could work for us, so I have been tackling all of the areas first that I thought might be problematical. This is due dilligence on our part before committing to the tools for our new product. Up to now all the problems that have arisen have either been due to my ignorance of the system, or there were workarounds that you suggested.

But spending two days trying to make this work has been frustrating.

Maybe these problems are just minor bugs that you will fix real soon, or perhaps my code is just plain wrong. I'm still hopeful.

thanks,

Terry

[aware_support2]

Terry,

> The new Account form does not show the list of stages.
At the moment it does not because the system does not consider your rule to be initialisation rule. We are removing this restriction within the next few days so the form will be showing the list when creating a new Account.

> If I click the Create button again the screen redraws and an "Account Object has been created" message is shown but the list of stages is still not shown.
This happens as a result of the default system behaviour. When you use New Object command from the generic menu (or operation of type Create Object when configuring a menu item), the system displays a form to let you enter data for the new object. When you click Create it saves the new object, displays message 'Record has been created. Create another record' and the form to enter data for a new object. Therefore, what you see after clicking Create is an empty form for entering another object, not the one that has been created. This default behaviour is designed to let users enter a series of objects of the same type without having to make another click to initiate the entry process again and again.

To override the default behaviour you can configure a process (called, say, CreateNewAccount) with the following two rules:

ENTER NEW Account
VIEW Account

and add a menu item (called, say, New Account) that will start CreateNewAccount process. What happens here is that once the object is created the system will display it again rather than move on to offer creating another Account as it does now. By the way, when it re-displays the Account form you will see the list of stages even with the current version of the software. Please try it and see how it works.

> Using the Edit button on the list of Accounts to go to the Account's form I see that the list of stages is shown, but the Completed attributes are displayed as a column of popup menus with three values: empty, Yes and No, and not as checkboxes, as expected.
Yes, you are right, the checkbox presentation option is currently not available for reference attributes with inline editing. We are going to implement this option within the next few days. We will post a message to this topic to let you know when the update is available.

[aware_support2]

Terry,

Build #743 is now available for download. It fixes both of the problems identified earlier in this topic, specifically:

- list of progress stages is not shown on the new account form.
- checkboxes are not shown in the progress stages list for attribute Completed.