Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-11602

Create extension points to override ExpressionEvaluator

    Details

    • Type: Task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.4
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Rice Module:
      KRAD
    • KRAD Feature Area:
      UIF Component
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      I’ve added an interface “ExpressionEvaluatorFactory”, to delegate instance creation to a singleton. This will facilitate both a global override via service locator, and per-view overrides at the helper level. I should have this ready to commit by tomorrow morning.

      Best,
      Mark

      From: Jerry Neal jkneal@iu.edu
      Sent: Tuesday, January 07, 2014 2:46 PM
      To: 'Mark Fyffe'
      Cc: 'Brian Smith'
      Subject: RE: Next Work

      Hmm, that is a good point. We usually don’t define services that way. Maybe skip the service locator, and just have it available through the view helper service like you originally planned.

      Thanks,
      Jerry

      From: Mark Fyffe mark.w.fyffe@gmail.com
      Sent: Tuesday, January 7, 2014 2:45 PM
      To: Jerry Neal
      Cc: Brian Smith
      Subject: Re: Next Work

      Sounds like a good plan, thanks Jerry.

      One item to note is that DefaultExpressionEvaluator at least must defined be a prototype. Should the service locator validate this, or can we trust anyone overriding ExpressionEvaluator to ensure their implementation is either thread-safe or defined as a prototype?
      Mark

      On Tue, Jan 7, 2014 at 11:45 AM, Jerry Neal <jkneal@iu.edu> wrote:
      Hey Mark,

      How about we add it to ViewHelperService as a member with standard
      getter/setter. Then the getter calls KradWebFrameworkServicelocator to get
      an instance. Then we default the service to use DefaultExpressionEvaluautor
      in spring beans. This would allow them to override it globally, and at a
      view level.

      Jerry

      ----Original Message----
      From: Mark Fyffe mark.w.fyffe@gmail.com
      Sent: Tuesday, January 7, 2014 11:31 AM
      To: 'Jerry Neal'; 'Brian Smith'
      Subject: RE: Next Work

      ViewLifecycleProcessor manages ExpressionEvaluator instances, but currently
      just calls new DefaultExpressionEvaluator() to create one. At least one
      ExpressionEvaluator instance is created per view instance. This behavior was
      moved from ViewHelperServiceImpl to resolve some thread safety and object
      creation overhead issues.

      I'll add a method "createExpressionEvaluator()" to ViewHelperService, with
      the default behavior calling new DefaultExpressionEvaluator(), and refer to
      this method when a new instance is needed. Sound reasonable?

      Which JIRA does this go on?

      Thanks,
      Mark

      ----Original Message----
      From: Jerry Neal jkneal@iu.edu
      Sent: Tuesday, January 07, 2014 10:59 AM
      To: 'Brian Smith'; 'Mark Fyffe'
      Subject: RE: Next Work

      Mark,

      Can you take a look at this and make sure there is a way to override the
      expression evaluator service impl? Just being able to globally override the
      implementation through spring will be fine.

      Thanks,
      Jerry

      ----Original Message----
      From: Brian Smith bsmith83@ad3.ucdavis.edu
      Sent: Monday, January 6, 2014 2:05 PM
      To: Jerry Neal
      Subject: Next Work

      I just committed the changes around expressions this morning. I am
      wondering what I should look at next, however there may be more to do here
      because even though the methods are now moved into the ExpressionEvaluator
      interface and its child DefaultExpressionEvaluator, I dont see how you would
      actually go about overriding them unless I am missing something obvious. We
      now get the evaluator for ViewLifecycle.getExpressionEvaluator which will
      create a DefaultExpressionEvaluator and return it if a
      ViewLifecycleProcessor does not exist, otherwise it pulls it from the
      processor, though I dont see a simple way to override the processor or
      ViewLifecycle either so not sure how this makes it easier to override. The
      jira is still open in the meantime until I have clarification on this.

      Thanks,
      Brian Smith

        Attachments

          Activity

          Hide
          mwfyffe Mark Fyffe (Inactive) added a comment -

          The ExpressionEvaluatorFactory pattern outlined in the issue description has been fully implemented and committed to the 2.4 performance branch. A merge of this one item to trunk has prove slightly more time-consuming that anticipated due to the need to manually merge several classes. The differences stem from renaming @NoLifecycle and @LifecyclePrototype to @ViewLifecycleRestriction, and also the migration of componentsForLifecycle and componentPrototypes to ViewLifecycleUtils.

          I have a few issues yet in unit tests, but have the new configuration bindings fully tied in at deployment time. I should have this one resolved early this week.

          Show
          mwfyffe Mark Fyffe (Inactive) added a comment - The ExpressionEvaluatorFactory pattern outlined in the issue description has been fully implemented and committed to the 2.4 performance branch. A merge of this one item to trunk has prove slightly more time-consuming that anticipated due to the need to manually merge several classes. The differences stem from renaming @NoLifecycle and @LifecyclePrototype to @ViewLifecycleRestriction, and also the migration of componentsForLifecycle and componentPrototypes to ViewLifecycleUtils. I have a few issues yet in unit tests, but have the new configuration bindings fully tied in at deployment time. I should have this one resolved early this week.
          Hide
          mwfyffe Mark Fyffe (Inactive) added a comment -

          Committed expression evaluator updates on Rice 2.4 trunk

          Show
          mwfyffe Mark Fyffe (Inactive) added a comment - Committed expression evaluator updates on Rice 2.4 trunk

            People

            • Assignee:
              mwfyffe Mark Fyffe (Inactive)
              Reporter:
              bsmith Brian Smith (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 2 hours Original Estimate - 2 hours
                2h
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 5 hours
                5h