Csla client-side customs agent service?

[swegele]

Wondering if there is a way to accomplish what I'm calling a "customs agent". It would be a service that sits at the entry point where objects go into and out of the DataPortal.

This service would have access to the ApplicationContext of objects on the client side (going into the DP) and the ApplicationContext of objects on the server side (right before coming back from the DP).

What I'd like is for this service to be able raise an event if the ApplicationContext (of an object coming back to the client across the DP border) meets some criteria (some bool flag). This would empower my client side to know that certain events happened on the server side of the data portal and do a subsequent response or refresh or whatever is appropriate.

Since no information flows back from the server to the client in ApplicationContext, I'm having trouble thinking of a way to accomplish this. Obviously scheduled polling could accomplish this where the client pulls information every so often...but that is expensive and 99% of the time useless.

Any ideas?

[swegele]

Self-reporting?

An alternate theoretical idea is to bake this feature into my base classes so that when they cross the border back onto the client-side, they can check the flag/condition and if it is true then the object could get the notification service via DI and then do the notification.

@rockfordlhotka can you tell me is the OnDataPortalInvokeComplete method called only once for the actual object that triggered the DataPortal call?
Also how would I identify the difference between a FIRST/REAL crossing/return of the dataportal from Client to Server (either logical/physical) as separate from calls to the dataportal that come from objects that are already on the server side (logical/physical).

So using LocalProxy
ObjectA calls DataPortal.Fetch
ObjectA on logical server side populates itself
ObjectA then calls child ObjectListB
ObjectListB populates itself
ObjectListB returns from it's logical dataportal trip (don't care about this because I'm still on server)
ObjectA finally returns from it's crossing the LocalProxy (here I would want to watch for the return and check the flag)

[swegele]

Would be nice to have a sequence diagram showing the timing of these following things in relation to each other as an object makes the trip:

• when the OnDataPortalInvoke event fires
• when the SetApplicationContext method is called the first time
• when the OnDataPortalInvokeComplete event fires
• when the SetApplicationContext method is called the second time

But there are so many combinations especially with different types of data portals...that would be a big task for sure.

[rockfordlhotka]

@TheCakeMonster has been contributing some work that might be along the lines of what you are talking about @swegele.

At some points in my books I have included flow diagrams for the data portal. Obviously they are no longer entirely accurate for CSLA 6, and so that'll be a key part of the next revision of the Using CSLA book.

The process flow for each request should not be hard to document. It should be the same in all scenarios, with you choosing whether to implement providers for your needs in each scenario. But the actual sequence of provider invocations should be consistent.

That said, some of the older providers might no longer really be valid now that we've fully embraced DI. There's a whole provider API (interface) that existed as a workaround for us not supporting DI, and that should probably be obsoleted over time, because it shouldn't be necessary any longer.

[swegele]

Yes I see the new interceptor stuff, that looks closely related....but then again I might be able to simply use OnDataPortalInvokeComplete

The key to this working is two-fold:

1. Can I distinguish between a DataPortal call that is completing from a true Client-side call vs a call that is completing from a chained Server-side call (see below for definition)
2. Most importantly Am I in the client side scope (not the temporary LocalProxy scope) so that my action/response has it's effect on the true client side. I need DI to function in the original client scope.

What is a chained dp call?
If ObjectFirst crosses dataportal for a Fetch operation and, WHILE IT IS ON SERVER SIDE, it instances ObjectSecond which calls the DataPortal to fetch itself (this is a chained dp call)...I don't want to respond/act to the completion of ObjectSecond. I only want to respond/act to the completion of ObjectFirst which means I'm truly back on the client now.

I'll have to play with both of these:

• Interceptor.Complete
• OnDataPortalInvokeComplete

I'll post here if I have any luck. In the meantime, if y'all have any ideas I'm all ears

[TheCakeMonster]

@swegele Yeah, I think your questions are key. When I first read your thread I wondered about interceptors as helpful. However, I then thought they are not the right solution, because they are on the server, not the client. However, @rockfordlhotka 's answer makes me question myself. We had to add guard clauses to our interceptor to ensure that it was only executed on remote data portals - but I think that was the point: we were discriminating between LocalProxy and everything else.

I think OnDataPortalInvokeComplete might be a better solution, if it works, as you want your behaviour on the client, not the server. I think interceptors are about logical server-side behaviour.

I can't think of any other client-side interception of this type. That's not to say there isn't any, but that I don't know of it.

The only other thing that springs to mind is deserialization events, but they happen for reasons other than data portal events, and happen on each object in a graph, rather than just the root.

I think the answer to your question is to try it. I think a bit of code will answer the majority of your questions, so that's what I would do next.

[rockfordlhotka]

Back when the client-side data portal was static there were some static events you could (with GREAT care) handle to know about client-side activity. Those (hopefully) don't exist anymore, and wouldn't be meaningful anyway, as the client-side data portal is now a transient instance.

The only real pipeline flow on the client side is via a custom proxy, because the client-side data portal basically packages up the message, gets the proxy, and asks the proxy to deliver the message and get the result. The result message is then handed back to the client-side data portal, which unpacks and handles it.

There's not much going on client side, and (to date) anything someone has asked for can be handled by a custom proxy.

[swegele]

So you think I could copy LocalProxy, and make my own CustomLocalProxy which does it's one additional thing right around the part where it does it's reset of the ApplicationContext? :

  ...Create/Fetch/etc
  ...
  SetApplicationContext(result.ReturnObject, OriginalApplicationContext);
  SetApplicationContext(result.Error, OriginalApplicationContext);
  return result;
}

That would be pretty handy to be able to have access to both the OriginalApplicationContext and the CurrentApplicationContext...very powerful.

[swegele]

@TheCakeMonster I think your gut reaction was correct (after looking more into it) both Interceptor AND OnDataPortalInvokeComplete fire too early to suit.

...and (to date) anything someone has asked for can be handled by a custom proxy.

@rockfordlhotka - So awesome that we can customize IDataPortalProxy! I think you're right, a CustomLocalProxy is the boy for me. I think I understand it enough to give it a try. After many years using Csla, we've always used the Local Data Portal so that is probably sufficient.

To be thorough, I should probably be able to do the same kind of client intercept should I ever use a physical data portal. In that case I think I'd still need a custom proxy, but would model it after one of these three HttpProxy - GrpcProxy - RabbitMqProxy. I think I'm getting it now.

Excited to try this out. Thanks to you both for the thoughts and feedback.

[TheCakeMonster]

@swegele It might be interesting to try to create a wrapper for another proxy - any other proxy - rather than a copy of any single one.

[rockfordlhotka]

Have you looked at subclassing the existing type? There are a number of protected members intended to support extensibility (though maybe not so much in LocalProxy as that's never been requested.

[swegele]

Yes, I think LocalProxy is the burr in the saddle on this one...

I did notice in the abstract class DataPortalProxy used by the three isremote portals there are these two:

• protected override async Task<byte[]> CallDataPortalServer(...)
  and
• protected virtual DataPortalResponse ConvertResponse(DataPortalResponse response)

The ConvertResponse seems the most likely to work (at least for the is remote scenarios).

[rockfordlhotka]

Maybe we can normalize LocalProxy to be like the others.

[swegele]

The only important thing I can think of when doing the LocalProxy "normalized thing" is to make sure and do it when its truly safe to assume that any DI requests will be acting on the client side service provider. That new scope thing is tricky.

[rockfordlhotka]

Do you want to create an issue to have LocalProxy subclass DataPortalProxy?