Seeking input: removing sync APIs from CSLA

[rockfordlhotka]

I'm seeking the community's input about the idea of (at some point) removing the sync APIs from CSLA.

Like removing the data portal Fetch, Create, etc. leaving just FetchAsync, CreateAsync, etc.

Here's a blog post explaining the thought, with a link to a poll for your input.

https://blog.lhotka.net/2024/05/23/Deprecating-CSLA-Synchronous-APIs

The blog post you to fill out this survey:

--survey closed--

Update: Here are the survey results:

https://blog.lhotka.net/2024/06/04/CSLA-Sync-API-Poll-Results

[StefanOssendorf]

I'm all for it :)

[Chicagoan2016]

Yes, even in my 'old' Winforms applications I use a lot of 'Async' code.
One other request, if possible could we add priority for 'Type' business rules(The ones that associated with the object)?
Regards

[rockfordlhotka]

One other request, if possible could we add priority for 'Type' business rules(The ones that associated with the object)? Regards

Please write up an Issue for this, describing how you would expect it to work.

[Chicagoan2016]

@rockfordlhotka , I have implemented 'use cases' where several properties have validation rules (with priorities), and when those rules are successful, I want to run a Type rule that will use the 'validated' properties.

[rockfordlhotka]

What you are describing is not supported by the current design of per-property and per-type rules.

Per-type rules are invoked on the type, not on an instance, and so currently can't do what you are asking. They are used by the data portal to determine whether the current user can create/get/save/delete/execute the type of object in question - not any specific instance of the object.

You'll need a per-property rule that does the required check(s), and attach that rule to all the properties in question. That'll really only affect whether the user can save/delete/execute the object, but that's also the only place such a rule would make sense - you can't have set properties on an instance that hasn't been created or retrieved yet.

[rockfordlhotka]

(oops - should have suggested this be its own thread - it'll get lost in this thread as it is totally off-topic)

[Chicagoan2016]

@rockfordlhotka , I will start another thread, I also misspoke (mistyped), I should have said object rules not per-type :)

[ajohnstone-ks]

Please no... I've been working full time since Dec 5th, with another dev full time since Jan 5th and significant help from the remaining 3 devs just to move from csla 5 to 7 b/c of the changes for dependency injection. Removing sync would force another top to bottom breaking change in the majority of our code. We're still not done either.

[rockfordlhotka]

Please do fill out the survey to help collect this feedback.

[ajohnstone-ks]

@rockfordlhotka Oh I did :-)

[rockfordlhotka]

The results from the poll are in, and there's a sizable result that would find the loss of sync APIs very problematic:

[StefanOssendorf]

For me this pictures says 3 are against removing sync APIs but 21 are okay with it within a timeframe. 🤔

[rockfordlhotka]

Yes, but I suspect we'd get similar responses for maintaining Windows Forms :)

Also, the overall response count is just 20-some people, so not conclusive in any case - just one bit of data to add to the conversation.

[rockfordlhotka]

Here is a link to a blog post with all the survey results:

https://blog.lhotka.net/2024/06/04/CSLA-Sync-API-Poll-Results