pxDropdown and Local Data Storage/Data Page
Hi all,
I recently (Feb 2015) completed SAE I and II training, which at the time was updated to v 7.1.6. One of the subjects we covered was Data Tables.
I started to create a Data Table via the Data Table wizard as we have been trained, but I see this in the Designer Studio
Data Tables have been replaced by the new local data storage format. Please click 'Convert' on each data table to convert them into the new format. To create storage for a new data type, go to the Data Explorer.
So, I created a local data storage item, with corresponding data pages (one for the page, one for a list of the pages). So far, so good.
I'd like now to use that list as the source of values in a pxDropDown that is defined on a property in my Case, but am somewhat stymied by the choices on the screen where I edit the source for the pxDropdown.
Again this is the "Display and Validation" section of the property of the data model, not the "add a pxDropdown in a Section", which appears to have different settings.
"Local List" just gives me a place to hard-code the values
"Field Value" , haven't really figured the prompts there out yet
"Class Key Value" , .likewise
"Remote list" looked promising but I can't seem to get the right things entered
"Prompt List" also doesn't make much sense
So, can I set up things this way? I'd like to have
- the property use a pxDropdown for display and validation
Hi all,
I recently (Feb 2015) completed SAE I and II training, which at the time was updated to v 7.1.6. One of the subjects we covered was Data Tables.
I started to create a Data Table via the Data Table wizard as we have been trained, but I see this in the Designer Studio
Data Tables have been replaced by the new local data storage format. Please click 'Convert' on each data table to convert them into the new format. To create storage for a new data type, go to the Data Explorer.
So, I created a local data storage item, with corresponding data pages (one for the page, one for a list of the pages). So far, so good.
I'd like now to use that list as the source of values in a pxDropDown that is defined on a property in my Case, but am somewhat stymied by the choices on the screen where I edit the source for the pxDropdown.
Again this is the "Display and Validation" section of the property of the data model, not the "add a pxDropdown in a Section", which appears to have different settings.
"Local List" just gives me a place to hard-code the values
"Field Value" , haven't really figured the prompts there out yet
"Class Key Value" , .likewise
"Remote list" looked promising but I can't seem to get the right things entered
"Prompt List" also doesn't make much sense
So, can I set up things this way? I'd like to have
- the property use a pxDropdown for display and validation
- have the pxDropdown use my local-data-storage-defined D_xxxxxxList as the source of values
***Updated by moderator: Marissa to close post***
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Accepted Solution
Pegasystems Inc.
US
Centene
US
This is the screen I'm referring to within the Pega Designer
Centene
US
If i go directly in to a Section, and just add a drop-down, it does give the option to use a Data Page List as the source of values in the drop down...a little confusing to be honest.
Pegasystems Inc.
CA
Hey Jim,
What you are noticing is the difference between the valid values for the field, and how it will be displayed in a section.
The Table Type is meant to be used for validation (though it can also be used for display). This is to force consistency when the property is used in multiple places.
The configuration of the UI Control (pxDropDown) has to be done in the section, where you can select a data page.
If you configure both, you are potentially setting yourself up for a situation where your dropdown has options that the property does not allow (for instance, if your data page has entries that are not in your local list) which will cause validation errors when you submit the form.
Hope this helped!
Ben
BNY Mellon
US
re: "If you configure both, you are potentially setting yourself up for a situation where..."
Bravo for Jim's question.
This should be addressed a future Pega release. It's needlessly confusing.
Most of the time, a given property with a dropdown should be bound to the source -- a foreign table or an in-memory data page (which itself is bound to that table).
It's unnecessary to push this choice to the displaying section.
Jon
Centene
US
Brendan
Thanks much for the very detailed explanation. I still don't understand why I can use the data page in one place, and not in another. In another development environment, I'd do something like
- always use database table xyz for the source of choices in a dropdown
- encapsulate that control in something that can be re-used.
In the two different places where I can define a dropdown, I am given the option of specifying a data source in one place, and not in another. There's my confusion (which still exists).
Jim
Pegasystems Inc.
US
Sure Jim. I hear you. While not an answer that provides any immediate returns, I'd say the best way to put it is as follows: The configuration options on the property rule form, while still viable options, are more representative of how we used to do things in older versions, before we leaned more heavily on our, now, much more robust data page architecture. The configuration options available in the section rule are representative of how we do things now. When put side-by-side there appears to be either at worst a true gap in functionality or at best a disconnect in how we have documented and provided training about the differences between the two. This gap/disconnect introduces confusion into what should be a relatively straight-foward concept. It's on us to take this feedback and evaluate the best course of action to eliminate this confusion in the future.
In the meantime, I would suggest you considering the UI configuration to be your central place for configuring your reusable UI components. I'd also suggest you looking into defining your own custom controls with which you can configure such things as your source of list options in one place which can then be associated with one or more different properties. But, that's just my perspective based on what I've always done. The ways in which PRPC can be used are infinite, I'm sure there are others who can share there own differing experiences in this area and I encourage them to do so. Discussions like these drive to the heart of why we are pushing this community,
Accepted Solution
Pegasystems Inc.
US
First, I want to acknowledge how I can see how this is confusing from your perspective. And to prove that those aren't empty words: Before I began working on this community project, I was a member of one our UI teams and am the guy who personally implemented the pxDropdown property panel for 7.x.
If my understanding is correct, there is confusion around what you can configure when defining the property itself as pxDropdown vs. what you can configure when you use the property specifically in the section.
If this understanding is correct, let me try to do my best to explain in the most basic sense. You have the ability to configure a property to default to be a specific type of control (such as pxDropdown) when used in a section. In addition, you can configure the property to have pre-defined values from a list of different options, none of which are "from a data page". These two statements are completely independent from each other. You can define a property to be a pxDropdown without defining values and vice versa. The general idea is reusability. If you have a property that you are going to use all over your UIs and 10 times out of 10 it's going to be a dropdown, by configuring it on the property, it will default to being a dropdown when you add it to a section via drag-and-drop or choosing the "Inherit from Property" option from the control menu.
First, I want to acknowledge how I can see how this is confusing from your perspective. And to prove that those aren't empty words: Before I began working on this community project, I was a member of one our UI teams and am the guy who personally implemented the pxDropdown property panel for 7.x.
If my understanding is correct, there is confusion around what you can configure when defining the property itself as pxDropdown vs. what you can configure when you use the property specifically in the section.
If this understanding is correct, let me try to do my best to explain in the most basic sense. You have the ability to configure a property to default to be a specific type of control (such as pxDropdown) when used in a section. In addition, you can configure the property to have pre-defined values from a list of different options, none of which are "from a data page". These two statements are completely independent from each other. You can define a property to be a pxDropdown without defining values and vice versa. The general idea is reusability. If you have a property that you are going to use all over your UIs and 10 times out of 10 it's going to be a dropdown, by configuring it on the property, it will default to being a dropdown when you add it to a section via drag-and-drop or choosing the "Inherit from Property" option from the control menu.
As for the "table type" configuration, I may be a *little* off the mark as far as technical description given the options available, but the easiest way that I've always thought of it is as a way to define a property's valid values when known. For instance, if the only possible values for my property are "A, B, or C", I'd configure the property to have a "table type" that defines these values (for simplicity's sake, let's say as a local list). Then no matter what control I use, the system will only accept one of those values or throw an error. Again, may not be the full intention of this field, but since we are talking about different perceptions, that's how I've always used it.
This brings us to the UI itself. When I am configuring a property in the section rule (note: Still trying to keep things simple, let's assume we are talking about a text property), I can pretty much configure it to be any control that I want, regardless of what I have configured it to be as a default on the actual property rule. So I could have configured a property to default to be a dropdown, but in the section rule, configure it to be radio buttons. In other words, section rule configuration trumps property rule configuration.
This brings us to using a data page. When I configure a property to use the dropdown control in the section rule, I am given the option to define how my list of options is sourced. If I have defined what essentially equates to a list of hard-coded valid values on my property as we just discussed, I would choose "as defined on property". But if I want to source my list from something more dynamic and variable such as the results stored on a data page or a page list generated by an activity, I chose one of those options and specify the page, class, and specific property the results are sourced from. (Which interestingly ties into another discussion you have about Pages & Classes, but one thing at a time).
So... Tying it all together. Can you define a "table type" with values on the property rule *and* configure the data page with results to use to list the options in the section rule itself? Absolutely. Should you, well, using my description as the property configuration being akin to valid values, probably not. Because if your data page provides a different list of results than the ones defined on the property, you will get an error.
Very long (but hopefully at least a little useful) story short: In your case, sounds like the best option is to not do much configuration on the property rule itself and do it in the section rule. If it's a piece of UI you plan to use in several places, implement the field(s) as a small section that can be included throughout your UI so you only have to do the configuration once.
Thanks.
B.
First, I want to acknowledge how I can see how this is confusing from your perspective. And to prove that those aren't empty words: Before I began working on this community project, I was a member of one our UI teams and am the guy who personally implemented the pxDropdown property panel for 7.x.
If my understanding is correct, there is confusion around what you can configure when defining the property itself as pxDropdown vs. what you can configure when you use the property specifically in the section.
If this understanding is correct, let me try to do my best to explain in the most basic sense. You have the ability to configure a property to default to be a specific type of control (such as pxDropdown) when used in a section. In addition, you can configure the property to have pre-defined values from a list of different options, none of which are "from a data page". These two statements are completely independent from each other. You can define a property to be a pxDropdown without defining values and vice versa. The general idea is reusability. If you have a property that you are going to use all over your UIs and 10 times out of 10 it's going to be a dropdown, by configuring it on the property, it will default to being a dropdown when you add it to a section via drag-and-drop or choosing the "Inherit from Property" option from the control menu.
First, I want to acknowledge how I can see how this is confusing from your perspective. And to prove that those aren't empty words: Before I began working on this community project, I was a member of one our UI teams and am the guy who personally implemented the pxDropdown property panel for 7.x.
If my understanding is correct, there is confusion around what you can configure when defining the property itself as pxDropdown vs. what you can configure when you use the property specifically in the section.
If this understanding is correct, let me try to do my best to explain in the most basic sense. You have the ability to configure a property to default to be a specific type of control (such as pxDropdown) when used in a section. In addition, you can configure the property to have pre-defined values from a list of different options, none of which are "from a data page". These two statements are completely independent from each other. You can define a property to be a pxDropdown without defining values and vice versa. The general idea is reusability. If you have a property that you are going to use all over your UIs and 10 times out of 10 it's going to be a dropdown, by configuring it on the property, it will default to being a dropdown when you add it to a section via drag-and-drop or choosing the "Inherit from Property" option from the control menu.
As for the "table type" configuration, I may be a *little* off the mark as far as technical description given the options available, but the easiest way that I've always thought of it is as a way to define a property's valid values when known. For instance, if the only possible values for my property are "A, B, or C", I'd configure the property to have a "table type" that defines these values (for simplicity's sake, let's say as a local list). Then no matter what control I use, the system will only accept one of those values or throw an error. Again, may not be the full intention of this field, but since we are talking about different perceptions, that's how I've always used it.
This brings us to the UI itself. When I am configuring a property in the section rule (note: Still trying to keep things simple, let's assume we are talking about a text property), I can pretty much configure it to be any control that I want, regardless of what I have configured it to be as a default on the actual property rule. So I could have configured a property to default to be a dropdown, but in the section rule, configure it to be radio buttons. In other words, section rule configuration trumps property rule configuration.
This brings us to using a data page. When I configure a property to use the dropdown control in the section rule, I am given the option to define how my list of options is sourced. If I have defined what essentially equates to a list of hard-coded valid values on my property as we just discussed, I would choose "as defined on property". But if I want to source my list from something more dynamic and variable such as the results stored on a data page or a page list generated by an activity, I chose one of those options and specify the page, class, and specific property the results are sourced from. (Which interestingly ties into another discussion you have about Pages & Classes, but one thing at a time).
So... Tying it all together. Can you define a "table type" with values on the property rule *and* configure the data page with results to use to list the options in the section rule itself? Absolutely. Should you, well, using my description as the property configuration being akin to valid values, probably not. Because if your data page provides a different list of results than the ones defined on the property, you will get an error.
Very long (but hopefully at least a little useful) story short: In your case, sounds like the best option is to not do much configuration on the property rule itself and do it in the section rule. If it's a piece of UI you plan to use in several places, implement the field(s) as a small section that can be included throughout your UI so you only have to do the configuration once.
Thanks.
B.