Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow use of custom properties as values or captions in the in the prevalue source based on Umbraco content #1195

Open
craigs100 opened this issue Mar 29, 2024 · 6 comments

Comments

@craigs100
Copy link

At the moment, we have the situation where the "Value" and "Caption" have to be the same. This is very rarely satisfactory if you're sending data to an end point.

image

Could we have the Value Field selection below the Root Node selection so that it shows all the fields of a child. The Caption can still be the Name of the child node. But at least we'd then be able to get much more use out of this prevalue configurator.

Thanks.

@AndyButland
Copy link

At the moment, we have the situation where the "Value" and "Caption" have to be the same.

If I've understood you right, this isn't quite correct. They will only be the same if you choose to have the "Name" as the "Value" for the prevalue (which was historically always the case). If you choose the more recently introduced "Id" or "Key" from the "Value field" drop down list, then that will be used for the "Value" of the prevalue.

The "Caption" of the prevalue is always the "Name" of the content node.

E.g.

image

Does that resolve what you are asking for here?

@craigs100
Copy link
Author

craigs100 commented Jun 19, 2024

I see what you mean, but what I mean is.....

Say your source node was Category List, I want to be able to select a field in the listed Category Pages as the Value, not just the page key, id or name.

So that would mean that "Value Field" dropdown would consist of Id, Key, Name plus all the field names on the child docType.

Also it would be better placed beneath the "Root node" dropdown.

Maybe it's just a dream but I thought it would be more useful like that. :)

I solved the issue by creating my own prevalue, but I just thought I wouldn't have had to if the above was true :)

@AndyButland AndyButland changed the title Change to the Umbraco Documents Prevalue set up Allow use of custom properties as values or captions in the in the prevalue source based on Umbraco content Jul 10, 2024
@bjarnef
Copy link

bjarnef commented Jul 10, 2024

Perhaps also allow to configure the label/text value.
It could be node name, custom property or perhaps event a combination of properties? e.g. nodeName (code)

@bjarnef
Copy link

bjarnef commented Jul 10, 2024

I also found the preview didn't perform well. We have many institutions/schools in a list archive and when using the list view as root it fetch all items at once.

In the case 4854 items. When rendering more than 500-1000 items with ng-repeat it is slow.

But something like this would help.

<tr ng-repeat="prevalue in prevalues track by prevalue.id">

@AndyButland could it at least list the data as paged results, e.g. 100 items per page?

Furthermore it would be great if the preview of the field in the form has a max height, so if dropdown checkbox list / radiobutton list contains 100 items, it doesn't have a lot of scroll on form page in backoffice 😅

@AndyButland
Copy link

I've added a limit to the preview to only display the first 5 items, followed by an ellipsis if there is more. Also added the track by to the preview display. Coming in 13.2 and 14.1

Paging feels like it might be masking an issue here though really - these prevalue sources are intended for drop-down lists, check box lists etc., which aren't paged on the front-end. So feels to me if you have thousands of items to pick from that's not really something to encourage for use on the front-end for the form display and entry.

@bjarnef
Copy link

bjarnef commented Jul 11, 2024

@AndyButland yeah, we would filter these further. However it makes the backoffice slow.

On frontend on could choose to use the prevalue source in a custom field type, e.g. a filtered/paged dropdown.

So it is more not the cause performance issues in backoffice. On frontend field types it is fine it just render options in a long list, but one could choose to use a custom field type instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants