CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum


CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • Async rule called during DataPortal_Fetch

    rated by 0 users
    Answered (Verified) This post has 1 verified answer | 3 Replies | 2 Followers

    Not Ranked
    2 Posts
    richardp.au posted on Thu, Feb 21 2013 1:08 AM

    Hi,

    I am using CSLA 4.2.2 with Silverlight (love it).

    I have a question about the use of async rules.

    I have some BusinessBase objects I fetch from the database.There is the possibility the database data can be incorrect, so I want to call BusinessRules.CheckRules() from within DataPortal_Fetch.

    In this way the CSLA PropertyStatus controls in the GUI will flag any errors even if the user has not changed anything.

    However I got caught out when doing this with async rules.

    It looks like if you call an async rule from within DataPortal_Fetch or Child_Fetch on BusinessBase, and there is not time for the rule to complete before the object is serialised, the IsBusy flag for the BusinessBase object is locked on.

    This causes weird GUI behaviour e.g. if you change the object you can never cancel the changes.

    Has anyone else seen this problem? I'm not sure if this is a CSLA bug or I am doing something wrong?

    I have worked around it by adding the following code to all of my async rules -

    if (ApplicationContext.ExecutionLocation != ApplicationContext.ExecutionLocations.Silverlight)

    {

    _log.Debug("skipping async rule check as we are not executing on Silverlight");

    context.Complete();

    return;

    }

    Of course this means all of my async rules are ignored on the server side.

    Kind Regards,

    Richard. 

    Answered (Verified) Verified Answer

    Top 10 Contributor
    2,279 Posts
    Verified by richardp.au

    You have 2 options (from my braindump)

     

    1. Make rule async on SL and sync on .NET Serverside.
      ie - CSLA have separate registration of rules on server and client and can set IsAsync to a configured value on the serverside and code the the execute method to handle both sync/async behavior. 
    2. Add code to your rule so that it will not run for a given condition (as you have). 

     

    Option1 makes your rule run in both client and server. 

    Starting from CSLA 4.3  (IIRC) rules can specify:

     

    • CanRunOnServer                    (when false - exclude from run in serverside of DataPortal)
    • CanRunAsAffectedProperty   (when false - exclude from run when this property is an affected property of another rule)
    • CanRunInCheckRules           (when false - exclude from run in CheckRules)

     

    I often find that especially async lookup rules should only run on the "rich" client side when a user changes the value, hence it is nice to be able to instruct the rule engine to not run the rule for a given set of conditions. This also means that the affected properties/input properties for excluded rules is ignored.

    Jonny Bekkum, Norway CslaContrib Coordinator

    All Replies

    Top 10 Contributor
    2,279 Posts
    Verified by richardp.au

    You have 2 options (from my braindump)

     

    1. Make rule async on SL and sync on .NET Serverside.
      ie - CSLA have separate registration of rules on server and client and can set IsAsync to a configured value on the serverside and code the the execute method to handle both sync/async behavior. 
    2. Add code to your rule so that it will not run for a given condition (as you have). 

     

    Option1 makes your rule run in both client and server. 

    Starting from CSLA 4.3  (IIRC) rules can specify:

     

    • CanRunOnServer                    (when false - exclude from run in serverside of DataPortal)
    • CanRunAsAffectedProperty   (when false - exclude from run when this property is an affected property of another rule)
    • CanRunInCheckRules           (when false - exclude from run in CheckRules)

     

    I often find that especially async lookup rules should only run on the "rich" client side when a user changes the value, hence it is nice to be able to instruct the rule engine to not run the rule for a given set of conditions. This also means that the affected properties/input properties for excluded rules is ignored.

    Jonny Bekkum, Norway CslaContrib Coordinator

    Not Ranked
    2 Posts

    Thanks Jonny that clears it up.

    Perhaps it would be a good to have the CSLA framework throw a SerializationException on any BusinessBase object that still had rules running at the time it was attempted to be serialized. That would make this situation very obvious. It took a little time to work out what was happening here and it definitely broke my app.

    Top 10 Contributor
    9,475 Posts

    Starting in 4.5.13 the data portal will throw an exception if IsBusy is true when the object tries to return to the client.

    https://github.com/MarimerLLC/csla/issues/33

    Rocky

    Page 1 of 1 (4 items) | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems