Need More Info
Last Updated: 23 Jul 2020 13:32 by ADMIN
Created by: tilt32
Comments: 4
Category: Grid
Type: Feature Request
4

Based on row values, I want to style the entire row.

It could perhaps be exposed through something like a "<RowDescriptor>" element inside the <GridColumns>

Need More Info
Last Updated: 20 Jul 2020 07:18 by ADMIN

ADMIN EDIT: Please review this thread and add your comments so we can get the community feedback on this.

Hello Team;

The Grid Popup is a great feature, but my understanding is that the Popup form ONLY shows properties that are assigned as columns to the Grid.
If true, this poses some restrictions for us. Many times we might show ONLY small # of columns in Grid, however the form requires MORE properties during ADD or UPDATE.
Is it possible that we can use two ViewModels, one for the Grid columns with less properties and one with more properties for ADD & UPDATE?

Note: If this FR is considered, perhaps we can have separate ViewModel for Update and ADD, as sometimes, ADD might require more properties to be added than later be updated.

This feature will save a lot of time to build apps that have many tables and we have to create CRUD operations

Need More Info
Last Updated: 03 Jul 2020 16:33 by ahmet
Created by: Marin Bratanov
Comments: 1
Category: UI for Blazor
Type: Feature Request
3

See more details in the following KB article: https://docs.telerik.com/blazor-ui/knowledge-base/textbox-validate-on-change and if the behavior and solution there do not fit your needs, leave your comments and ideas on how you want this exposed for configuration and what the desired behavior is. Also, make sure to Vote for this enhancement so we can gauge the public interest in it.

Need More Info
Last Updated: 28 Jun 2020 11:56 by ADMIN
Created by: Marin Bratanov
Comments: 4
Category: TreeView
Type: Feature Request
0

Hi everyone,

We created this item to request your feedback on how you use the treeview binding with regards to the Expanded state of the nodes.

At the moment, the treeview updates the field in the collection when an item gets expanded or collapsed, and that makes it unique in the suite - the other data bound components do not alter their data source silently, and this is the general pattern we want to follow in order to have consistency across the board.

Thus, there are several approaches we are considering and we want to get your take on how you would find this most comfortable:

  • Keep the current situation where the treeview updates the ExpandedField in the Data silently [we would rather change it] - the Data collection gets changed automatically. To control an expanded item, prepare the data source accordingly.
  • Use the OnExpand event to get the item and its new state in order to update the collection yourself if needed. If you don't use the field for anything but to control the state of the treeview, you will not need to change anything. To control an expanded item, prepare the data source accordingly when providing it to the treeview. If you will be reusing the same data source with alterations, you may have to handle the event to sync the state between the treeview and the data.
  • Use an ExpandedItems collection [we are inclined to go with this approach at the moment] - this will be a collection that you can provide to the treeview separately from its data source, like the selected items in a grid. This will let you avoid an Expanded field in the data (which we believe may not be present in an actual database anyway) and you will be able to use business logic to determine which items to add/remove to that collection, this also includes nested levels, even added through load-on-demand.