Road Map/New Features

Hello Radzen team,
do you any suggestions about the release date of the following points fom the roadMap?

Reusable components
Create mini-pages that can be reused. Compose in other reusable components or pages. Set properties from the property grid.

Data-binding editor
The current way of data-binding via ${} expressions is really powerful and provides a lot of control.
This feature will allow the developer to visually data-bind component properties - pick from the existing page properties or define new ones.

Page templates and wizards
More page templates to simplify the creation of common pages - search with data grid, data grid and form et. al.

Waiting for it… :slight_smile:
Kind Regards

Hi @ThomasS,

We are currently working on shipping the new themes and addressing any visual glitches and inconsistencies people have reported in the past. Once this is done we will start working on the items you have listed. The order will probably be:

  1. Page templates and wizards
  2. Data-binding editor
  3. Reusable components

Frankly the Reusable components feature hasn’t seen much interest and requires the most effort to implement. There is a great chance that we may decrease its priority.

A tentative release date for the first two items is Mid October. We will update our roadmap in case our priorities shift.

The issue of customizable Referential Integrity rule would be quite high on my list :slight_smile:
I have 2 concerns about this:

  1. Forcing a Cascade Delete without the option of a Restrict Delete is a major issue to me
  2. I am not sure how your logic works anyway beyond the first generation of children: suppose I have table A with a 1 to many relationship to table B, and table B with a 1 to many relationship to table C and my SQL database has defined all those relationships with Restrict Delete integrity rules: if I delete a record in table A via Radzen, your logic will override the 1st Restrict Delete but I believe the 2nd would prevail… Am I right? (did not test this)

Hi @semafox,

At the moment Radzen uses the default cascade delete behavior that Entity Framework Core provides. If the foreign key is nullable it doesn’t do anything to child entities when their parent is deleted. When the foreign key is not nullable it deletes the children entities in the DB. Which behavior from the supported ones would you like to use?

I would need the ability to override the EF default behavior for each relationship with either Cascade, SetNull (if nullable) or Restrict…

I see. Creating the UI for setting the cascade delete rule should ideally be a diagram of the whole DB, showing the relationships. Developing such a feature would take some time and won’t happen soon.

The good news is that you can set the cascade delete rule even now with code. Here is how to do that:

  1. Create a <DataSource>Context.partial.cs file in server\Data e.g. NorthwindContext.Partial.cs
  2. Define a OnModelBuilding method and specify the cascade delete for every relationship needed:
namespace Northwind.Data
    public partial class NorthwindContext
        partial void OnModelBuilding(ModelBuilder builder)
              .HasOne(i => i.Category)
              .WithMany(i => i.Products)
              .HasForeignKey(i => i.CategoryID)
              .HasPrincipalKey(i => i.CategoryID)
              // Set cascade delete behavior

Radzen has generated all relationships in the Context.cs file and you can copy the ones you need and paste them in the partial class adding the cascade delete behavior.

Will that work?

This would work great of course, but I am a bit confused since this code (without the .OnDelete) is already executed by OnModelCreating()… Is it ok to execute it twice?

As far as developing the UI for setting the Referential Integrity rule of each relationship, you do not need to. You could simply give the option to import the settings of the database: let the relationships in the EF reflect what they are in the Database… Just a thought.

I think it is OK to execute it twice - the one from the partial class should replace the other.

We will investigate how this can be done and implement it if possible.