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

Add rules engine to BusinessListBase #1830

Open
rockfordlhotka opened this issue Oct 5, 2020 · 4 comments
Open

Add rules engine to BusinessListBase #1830

rockfordlhotka opened this issue Oct 5, 2020 · 4 comments

Comments

@rockfordlhotka
Copy link
Member

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. ???

@luizfbicalho
Copy link
Contributor

In this one is there a list of the interfaces that should be implemented on the BusinessListBase<T, C>?

@rockfordlhotka
Copy link
Member Author

I haven't fully thought this through, but at a high level my thinking is to merge all the code in the Csla.BusinessBase class tree (including its base classes) with the code in BusinessListBase.

Or maybe the better way to say it, is to merge everything from BusinessListBase into BusinessBase.

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 BusinessBase and BusinessListBase.

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 BusinessBase, because people still create and maintain Windows Forms apps. But we can add this capability to BusinessListBase (or maybe we should create a new type?), because Windows Forms already can't use BusinessListBase (for WinForms you need to use BusinessBindingListBase).

@luizfbicalho
Copy link
Contributor

One way we could do this is to create a new class that implement all interfaces and has one private property BusinessListBase and one private property BusinessBase
this way the logic is still inside each one, and we can merge them

do you think that this is one possibility?

@rockfordlhotka
Copy link
Member Author

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 BusinessBase and BusinessListBase need to be raised by the aggregate type as well.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

2 participants