Any ideas for an overridable method or event (existing or theoretical) signaling arrived back on the client side?

[swegele]

Asking as a separate question worded differently to see if fresh ideas bubble up (see this for history)

I've racked my brain since CSLA 6 release trying to figure out where if anywhere I could or would have some reliable place in code to detect that we are back on the client AFTER a DataPortal call AND where I would have access to interesting relevant things like:

• any object(s) that came back
• any exception(s) that came back
• maybe even the ApplicationContext that WAS in effect on the server side if we were using the LocalProxy (since it's right there in memory from the other scope)

Ideally this mysterious method/event would happen only once per call to the DataPortal
It should work regardless of whether the DataPortal was remote or local
It shouldn't cause nasty memory leaks or dangerous events that shouldn't exist - maybe it would be consumed by some scoped service that can do important big picture things depending on what it sees at the time

Is this making any sense?

As a reminder: for server side - we already have several methods/events like OnDataPortalInvoke and OnDataPortalInvokeComplete that happen in business objects. These can be overridden in base classes. THE PROBLEM is that both fire on the server side (logical or physical depending upon the proxy used).

[swegele]

It occurs to me that someone might think "Well you've already got what you asked about in the response of all calls to a DataPortal.Fetch or Create etc.". Well yes, I could code a common handler into every CRUD operation method on every business object...which would be several hundred x 4...that's a lot of boiler plate code to add.

Ideally there is some way to add a hook ONCE to the DataPortal<T> or something similar so that I could watch all traffic departing and arriving back to the client side...and do interesting generic/common things if a condition is detected requiring action.

Example: maybe all my business objects implement an interface that adds a common property (implemented in the base class) which if true on the way back from the data portal means do some action.

[rockfordlhotka]

There used to be some static events when DataPortal was a static type. That was never a good design choice because it too easily led to memory leaks. Fortunately I don't think anyone noticed those events! 😂

Now in modern CSLA, with each instance of IDataPortal<T> being transient (and instanced), I think it is probably realistic to raise an event - though I'm not sure of the value, which is why there isn't such an event.

Normally your calling code is like this:

  // got portal via injection
  myResult = await portal.FetchAsync();
  // more code

In that context it isn't clear to me what an event would add, given that you know when the result returns because the "more code" only runs after the result is back.

Where would you use an event here?

(and you might say that it is useful in some MVVM scenarios - and I agree - which is why the various CSLA ViewModel types mostly (?) have a way to know when async operations are complete)

[swegele]

See #3546 - I'm took a stab at creating 2 more extensibility points that devs could potentially hook into for watching things when execution comes back to the client side.
(I did my best trying to create clear method names and good comments...but obviously please feel free to redline)

1. By subclassing LocalProxy, a DEV gets a hook to a new virtual method RestoringClientSideApplicationContext enabling easy inspection of the ApplicationContext that was being used in the separate scope during the logical server side operations. This is very powerful, but it is unique to the LocalPortal and thus I also added number 2 below for different scenarios.

2. DataPortalProxy now has a virtual method ReturnedToClientSideAndPreparedResult which works for all types of DataPortal proxies.
   It gives a DEV a single point of inspection for all objects coming back to client side. It's like a place where you could implement kind of a client side customs agent. So I can inherit from LocalProxy or HttpProxy etc. and get a hook into this method.

[rockfordlhotka]

Is your goal for individual domain business objects to be aware that they've rematerialized on the client?

Or for a subclass of a proxy to be aware that an object graph has rematerialized on the client?

[swegele]

The later is what I’m after, So a subclassed proxy that watches all the objects

…

On Wed, Nov 8, 2023 at 10:11 PM Rockford Lhotka ***@***.***> wrote: Is your goal for individual domain business objects to be aware that they've rematerialized on the client? Or for a subclass of a proxy to be aware that an object graph has rematerialized on the client? — Reply to this email directly, view it on GitHub <#3541 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABUM5P5P4CBPH2ADCZC7QSTYDRQZ5AVCNFSM6AAAAAA7CDQXKWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKMJYGE3DM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[swegele]

Well I should say at first I didn’t know where it was possible or best to hook in - but now that I’ve spent a bunch of time in the Csla guts I see the proxy seems the most natural place for what I’m thinking. But to your question- the proxy could certainly tell the object he is on the client through some base class method. That might come in handy someday although I don’t have a use case for that currently.

…

On Wed, Nov 8, 2023 at 10:11 PM Rockford Lhotka ***@***.***> wrote: Is your goal for individual domain business objects to be aware that they've rematerialized on the client? Or for a subclass of a proxy to be aware that an object graph has rematerialized on the client? — Reply to this email directly, view it on GitHub <#3541 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABUM5P5P4CBPH2ADCZC7QSTYDRQZ5AVCNFSM6AAAAAA7CDQXKWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKMJYGE3DM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[swegele]

Fair question. To answer succinctly but with enough information to help it make sense. About a year and a half ago we set out to accomplish 2 goals:

1. Update all projects (BL, automated tests, Web APIs) to .net 6 and CSLA 6
2. Update the flagship WebForms app to Blazor Server Side

We accomplished number 1 in a few months with automated tests passing and Web APIs working. We've been on the WebForms to Blazor translation ever since - we're ~75% done. There is only one use-case that I haven't yet been able to accommodate in the translation. Here is an example of that use case which has about 10 or so variations.

• In old version and in new version (probably forever) we only use the Local DataPortal. No need for a remote.
• We are in a protected environment and choose to flow our user principal from client to server side
• "Joe" is logged in and is an administrator
• Joe goes into system administration and edits security role permissions
• During the DataPortal Insert/Update processing, the editable business object detects that the logged in user (ApplicationContext.User) roles need to be updated.
• The ApplicationContext.User gets updated, all the remaining operations on the logical server side get the updated User.
• In CSLA 6, upon return to the LocalProxy client side...the server scoped context is tossed and the client side context is restored.
• In the CSLA 5 system ApplicationContext was static and so all was well. But now when using UseLocalScope it is separate ref (in Blazor Server Side anyway). So now I have a challenge for someone/something on the client side to know "The logged in user needs a to be refreshed" before continuing.
• There are about 10 of these types of operations that currently cause a change on the server side where I want to know something happened back on the client. It is possible for me to add code to every one of those places to do some test but that is onerous and prone to DEVS forgetting. Better if I can ubiquitously detect a change right at the time of context switch.

Firstly I added the virtual method extensibility point to LocalProxy called RestoringClientSideApplicationContext. This allows me to inspect the context from the server side of LocalProxy while I have the client side context handy at the same time for comparison.
Picture a customs agent comparing a picture of a guy taken when he got on the plane going overseas and comparing it with the actual guy who standing in front of him having returned. He looks for changes and responds appropriately. (sorry for the stupid example)

Secondly, I wanted to go the extra mile to create an additional DataPortal type-agnostic way to accomplish the same thing in case we ever find ourselves needing to use a remote Data Portal. It is similar to the first way by having the hook in the proxy...but it is accomplished by attaching a piece of information (a property implemented in base class) to my business objects on the server side to take back to the client side. The data portal knows to check for that piece of information on business objects coming back to client.
Picture a customs agent looking at people getting off the plane. Agent has been told "if you see anyone with a red scarf you need to get the note from their right coat pocket and give it to your supervisor". The object doesn't know and doesn't have to do anything other than having something in his pocket for a bit.
The new ReturnedToClientSideAndPreparedResult virtual method in DataPortalProxy makes this 2nd use case possible.

Make any sense? I think the code I've added adds a nice couple options/features while not breaking anything or causing perf slowdowns...even if what I'm doing seems dumb?

[swegele]

See comment/suggestion by cake monster related to Results<T> flowing back through portal.

My second virtual method ReturnedToClientSideAndPreparedResult could be used to empower a generic ErrorHandler which has an opportunity to generically process errors coming back from server side before execution gets back at the original caller. Thinking out loud about possible other use cases.

[rockfordlhotka]

I read the argument from @TheCakeMonster and generally agree. I wish my thinking in either 1997 or 2001 would have involved the idea that a service returns one of: success-yes, success-no, or exceptional failure.

Rethinking the data portal to use that model would be a massive break, and yet it is a change that should happen.

I am not keen to do any band-aid type workaround, as much as really think it through and develop a different/new "data portal" construct that implements that thinking from the ground up.

[rockfordlhotka]

To specifically focus on your core request, what you are describing sounds like a side-effect, where you called the data portal to do one thing, and it also did something else.

That's not good, at least as a general practice. I'm not keen on directly supporting side-effects that aren't explicitly part of the domain model.

Which is to say that I think your scenario(s) should be explicitly part of your business domain model, not part of the infrastructure.

[Serializable]
public class EditRole : BusinessBase<EditRole>
{
    // do what you do today
}

[Serializable]
public class EditRoleUoW : ReadOnlyBase<EditRoleUoW>
{
    // property EditRole for EditRole

    // property NewPrincipal for new ClaimsPrincipal

    [Fetch]
    private async Task FetchAsync(EditRole editRole)
    {
        EditRole = await editRole.SaveAsync();
        // if current user was changed then
        NewPrincipal = new ClaimsPrincipal(...);
    }
}

Now there's no undocumented side-effect, because the domain model explicitly demonstrates what happens (or could happen) when you execute the EditRoleUoW operation.

  var result = await portal.FetchAsync(editRole);
  SetCurrentPrincipal(result.NewPrincipal);
  editRole = result.EditRole; // update reference or use graph merger or whatever

[swegele]

I agree with you ... yet I still think it would be nice to have these two extensibility points added.
I'm getting to know you a little because I had a hunch you wouldn't approve of how I planned on using these methods...which is why I said...

I think the code I've added adds a nice couple options/features while not breaking anything or causing perf slowdowns...even if what I'm doing seems dumb?

"Do no harm"
I'm humbly trying to make a case that the two abstract methods empower users while causing no harm.
I remembered you had a similar concern here My philosophical argument then could be copied and pasted here.
Incidentally I wonder if literally anyone else has ever used the public T GetRequiredService<T>() that you kindly added/obfuscated for me? It sure made my life sooo much easier :-)

So anyway...could we make these two new proposed abstract methods [EditorBrowsable(EditorBrowsableState.Advanced)]?

Arguably CSLA provides a plethora of places on the server-side where I can intercept "in a generic way" to do fun things (otherwise known as undocumented side-effects).
Example:

1. Intercept all OnDataPortalInvokeComplete operations through base classes
2. Send the DataPortalEventArgs to a scoped service called DoSneakyThings
3. DoSneakyThings service does...well...mysterious stuff and perhaps even manipulates the DataPortalEventArgs.Object property with no one being any the wiser.

I enjoy our discussions.