Yes, this makes sense! A user could create an OData function/action and Radzen should be able to “see” it later. Registering the OData function needs a few “escape hatches” but is definitely possible. Adding it to the backlog.
Thanks. I’d say the ability to model simple queries at designtime would be preferred so it doesn’t regenerate upon full infer from Sql but a refresh from OData meta would be a nice interim option.
Besides designing database queries what are the other missing features that LightSwitch developers would could ask for?
A big one is the ability to define relationships with full navagation properties supporting $expand etc across two different datasources. Like relate customers in CRM to cases in zendesk for example.
This is a potential benefit of generating a single server tier for every app. The server is like a middle tier that mashes any number of disparate data sources exposing them as one OData service and making a place for common serverside business logic.
In that way, LS was useful for generating the OData service and backend logic alone even without the UI.
What was always missing from LS, and contributed to its downfall IMHO, was the fact that the build and gen templates were a black box - never made available to users. Radzen’s simplicity in the use of swagger for meta and .ejs for generation could change that and open your awesome tool to community contribution making the horizon endless. Thanks for listening.
Back in the day, the LS community discussed vNext wish list. I’ll review some old posts on forums and share them here.
Atanas,
Reviewing some old posts this morning. My RadZen enthusiasm has been awakened as has my LightSwitch nostalgia.
Regarding above, does Radzen do:
- design-time query builder
- server-side parameter queries
- single back-end over mutilple data sources
- cross-data source relationships
- refresh data source operation from the dot net backend, instead of full infer from sql
Thanks,
Josh
1 Like
Hi @joshbooker,
Here are my responses:
design-time query builder
We have the Query Builder that allows one to create queries from Radzen.
server-side parameter queries
Probably covered by the Invoke custom action.
single back-end over mutilple data sources
Radzen creates a single backend .NET project that handles all DB-based data sources. The OData data source is currently handled client-side.
cross-data source relationships
Not supported.
refresh data source operation from the dot net backend, instead of full infer from sql
Radzen will regenerate the code for the backend only when a data source is inferred again from the DB.
Took a trip in the way-back-machine to procure some applicable threads from the old LightSwitch forums. They’ll be a mix of wish-list and ranting, but youll probably find something useful in each.
Here you go:
https://social.msdn.microsoft.com/Forums/en-US/dda39caa-1761-4e8a-a331-5bd4bbdaf45a/rip-lightswitch
Thanks Josh. I have seen both threads and even contacted some of the participants.
Here are my responses:
design-time query builder
We have the Query Builder that allows one to create queries from Radzen.
I like the new Query Builder, will have to try that out. Would be nice to design server-side queries at design-time in a similar way.
server-side parameter queries
Probably covered by the Invoke custom action .
While you can do something similar via custom actions, the return values are not typed entity sets and cannot be used in the same way as regular entities at design time. Like how would I easily create a screen on a custom action result? Please review our detailed discussion in this thread above from Oct'17.
single back-end over mutilple data sources
Radzen creates a single backend .NET project that handles all DB-based data sources. The OData data source is currently handled client-side.
Would be swell if the backend was created for all data sources and an application object enabled us to work across data sources. Like MyApp.Data.Northwind.Customer was usable in controller for myApp.Data.CRM.Account. I think an application context server-side is a first step toward being able to have a business logic middle tier. and also for the next suggestion from LightSwitch cross-db virtual relationships.
cross-data source relationships
Not supported.
Bummer. Ability to do a mashup and easily handle navigation properties was one of LS best features.
refresh data source operation from the dot net backend, instead of full infer from sql
Radzen will regenerate the code for the backend only when a data source is inferred again from the DB.
See above discussion for use case. This was to allow folks to add functions in controller code and RadZen would 'see' them at design time. A work around for lack of server-side queries designer.
Anyway, that's my LightSwitch-inspired wish list for RadZen from last year. That plus better Azure AD Auth and Deploy support. Thanks so much for your effort! Keep up the great work! RadZenRocks!
Josh
Thanks for your feedback!
I like the new Query Builder, will have to try that out. Would be nice to design server-side queries at design-time in a similar way.
We have to think how to avoid a confusion with the existing query builder.
While you can do something similar via custom actions, the return values are not typed entity sets and cannot be used in the same way as regular entities at design time
If we find a way to infer the type of a custom action result it will appear as other entities in design time. At the moment one can still use the result of custom actions to make pages. The only missing feature is design time autocomplete.
Would be swell if the backend was created for all data sources and an application object enabled us to work across data sources. Like MyApp.Data.Northwind.Customer was usable in controller for myApp.Data.CRM.Account. I think an application context server-side is a first step toward being able to have a business logic middle tier. and also for the next suggestion from LightSwitch cross-db virtual relationships.
Generating a backend for the other data sources is doable albeit a breaking change. We will consider that still.
Bummer. Ability to do a mashup and easily handle navigation properties was one of LS best features.
This is quite a challenge to support as it would require a few other things to be implemented beforehand.
That plus better Azure AD Auth and Deploy support.
What would constitute a better Azure AD and deploy support? More descriptive UI or something that is currently missing?
Azure OAuth:
I think you're on the implicit flow problem with pending hotfix.
Credentials grant would be nice.
Azure Deploy:
from tool without going to portal would be nice. As mentionedhere. Even if it's just AZ CLI or config azure continuous delivery & git push
A wizard with the following flow would be ideal:
- Deploy to IIS or Azure? Azure...
- Existing app service or new
- Existing site or new
- Enable continuous integration from git.
- Push to github
Oh yeah and one-click debugging either/both client and server in vscode like:
Thanks for listening!
We have to think how to avoid a confusion with the existing query builder.
Since the server-side query builder would likely be triggered in the datasource setup area it's probably not confusing.
If we find a way to infer the type of a custom action result it will appear as other entities in design time. At the moment one can still use the result of custom actions to make pages. The only missing feature is design time autocomplete.
Do you mean the custom action now shows in the Page Schema Selection? (New Page > CRUD pages >Page Schema) Or you mean user can manually create property on the page then invoke the action then set property then bind grid data to the property? If the latter, then we're missing some new page wizard functionality as well. Also missing CRUD, on custom action results, correct?
Generating a backend for the other data sources is doable albeit a breaking change. We will consider that still.
The main benefit is that the server tier becomes like a shared middle tier. A place for the custom business logic. Sure it's overkill for someone who wants just forms over existing OData service so make it optional. But for those of us from LightSwitch who want to mashup multiple datasources and also do things like cross-datasource virtual relationships (SQL entity related to another SQL entity in a remote db related to an OData entity in some cloud system) it's amazing. I know this is probably a version 3+ thing - if ever. Just one of my fav features of LightSwitch.
Now that I think of it, all this happens in the data area. Think of datasource setup area being more than one-may read schema. It's that plus user defined display names and plural names; server queries; virtual relationships; permissions Customer_canRead, Customer_canUpdate, etc; actions Customer_Updating, Customer_Updated - all user defined at designtime and all generated into a shared server tier having Entities as objects addressable in controllers like MyApp.Data.someEntity.
Thanks again for listening.
Keep up the great work!
1 Like
Do you mean the custom action now shows in the Page Schema Selection? (New Page > CRUD pages >Page Schema)
Custom actions show only in the Action picker when handling events.
Or you mean user can manually create property on the page then invoke the action then set property then bind grid data to the property?
Yes. This is how it is done in our tutorial.
Also missing CRUD, on custom action results, correct?
CRUD wizards work with entities only. CRUD with custom methods will require the usual event handling / set page property implementation.
Think of datasource setup area being more than one-may read schema. It's that plus user defined display names and plural names; server queries; virtual relationships; permissions Customer_canRead, Customer_canUpdate, etc; actions Customer_Updating, Customer_Updated - all user defined at designtime and all generated into a shared server tier having Entities as objects addressable in controllers like MyApp.Data.someEntity.
I think you described LightSwitch here 
We can't (legally and technically) make a 1:1 clone of LightSwitch and call it Radzen.
The Customer_Updating is supported from the beginning via partial methods.
I know it’s asking a lot but hardly a clone. RadZen is much better. Just think some more user config on the data side which necessitates a server middle tier is the icing on the cake.
Thanks for listening.
2 Likes
@joshbooker thank you for explaining so well what we are still missing from LightSwitch and which would make Radzen an over the top product. It is truly amazing how much LightSwitch gave us... yet Radzen has some cool stuff LightSwicth never offered...
2 Likes