-
-
Notifications
You must be signed in to change notification settings - Fork 404
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
Add rules engine to BusinessListBase #1830
Comments
In this one is there a list of the interfaces that should be implemented on the |
I haven't fully thought this through, but at a high level my thinking is to merge all the code in the Or maybe the better way to say it, is to merge everything from This is going to be a really big task, because the goal is to have a combined base class that can do everything you can do with And if you want just a type with properties, you can do that. And if you want a type that's a collection, you can do that. And if you want a type that has some properties and is also a collection, you can do that. The reason it doesn't work this way already, is that Windows Forms (the original .NET platform supported by CSLA) has no concept of a collection type that also has properties. Or Web Forms. If I think back, I probably should have created a consolidated type when WPF came out, because XAML does support this concept. So we can't break |
One way we could do this is to create a new class that implement all interfaces and has one private property do you think that this is one possibility? |
I think that is an interesting idea. To do this we should be able to implement just two interfaces - the top-level interfaces that aggregate all the BusinessBase and all the BusinessListBase behaviors. Your thought is to then have this new class delegate into the private "child" objects for all the interface elements? The other aspect to keep in mind is that all the events raised by The final thing that comes to mind is to figure out how this aggregate type will serialize, which should be fairly easy I imagine, because it can implement the get/set children methods and enlist the two "child" objects as children for serialization. |
In the past there was no way to data bind to properties of a collection, and so the collection base types have never had a rules engine built in.
Really since XAML though, it has been possible to bind to properties of a list. That's now true in Blazor as well as XAML (and I think in Razor Pages as well).
At the very least, it should be possible to have rules that run when a child changes, resulting in output property values that change properties of the list itself.
This requires some research and serious thought - as it could lead to BusinessListBase having most/all the same logic and capabilities of BusinessBase. ???
The text was updated successfully, but these errors were encountered: