Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-11602

Create extension points to override ExpressionEvaluator

    Details

    • Type: Task Task
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.4
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-3926Override SequenceStyleGenerator to handle Strings
      KULRICE-4012Research possibilities for BO Extensions
      KULRICE-2593Review various Spring override points in the codebase and clean them up
      KULRICE-11390Create Automated Functional Tests for KRAD Labs - Maintenance Sample - Override Values
      KULRICE-10210Rename GloballyUniqueAndVersionedBase to DataObjectBase and add @Transient extension object
      KULRICE-6845Problems with UifBeanFactoryPostProcessor expression handling that is causing bean property overrides (such as fieldInquiry.render) to not work
      KULRICE-13340IT Failure Jiras pointing to wrong CI
      KULRICE-8425Problems with UifBeanFactoryPostProcessor expression handling for nested properties and lists prevent bean property overrides (such as fieldInquiry.render) from working
      KULRICE-8902CI Smoke tests fail with Xlib: extension "RANDR" missing on display ":20".
      KULRICE-12040Allow for overridding of view lifecycle phases and tasks
    • 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

        Activity

        Hide
        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
        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
        Mark Fyffe (Inactive) added a comment -

        Committed expression evaluator updates on Rice 2.4 trunk

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

          People

          • Assignee:
            Mark Fyffe (Inactive)
            Reporter:
            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

                Structure Helper Panel