Details

    • Type: Task Task
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Not version specific
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-5323Dataset Consolidation
      KULRICE-111Simplify UI control pluggability
      KULRICE-1306Data/DDL consolidation and bootstrap process
      KULRICE-6321Database script consolidation for release
      KULRICE-10878Simplify ObjectPropertyUtils
      KULRICE-11597Generated lookup/inquiry ids contain invalid characters
      KULRICE-13283Grouping classes and ids bad for row grouping in collection
      KULRICE-8424Consolidate database scripts for release
      KULRICE-2177Consolidate all Rice Struts modules into a single struts module
      KULRICE-7871Checkbox and Radio Group ids are not correct
    • 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

      Cleanup item moved from KULRICE-9997:

      Extract ID assignment code (org.kuali.rice.krad.uif.service.impl.ViewHelperServiceImpl#preprocessView) to helper method or class, along with Component State, Create helper methods to reduce nesting and duplicate code

      Related discussion:

      Mark,

      Right. So we could change AssignIdsTasks to use the same code as ViewHelperServiceImpl#preprocessView, that is using the path instead of the index?

      I think the concern with testing, even after we get the things stable, is if a developer makes a change that moves the component (say push it down in a list or something of that sort), the scripts would need to be modified. If we had a way of generating the Ids (for example based on name for inputs), that would allow for more stable tests.

      Thanks,
      Jerry

      From: Mark Fyffe mark.w.fyffe@gmail.com
      Sent: Thursday, December 12, 2013 8:22 AM
      To: 'Jerry Neal'
      Subject: RE: ids

      This does make sense. Now that path is available by virtue of getComponentsForLifecycle(), it should be feasible to universally assign ID based on path.

      There are several cases where components are dynamically created and added to the lifecycle, particularly during the apply model phase. Although it doesn’t do so right now, spawnSubLifecycle can assign the path in these cases making path a viable seed for generating the IDs even for new components. This won’t help the generateAndAssignIds() method used by LightTable and BreadcrumbOptions, however, since the purpose of this method appears to be to discard existing and assign new IDs to all components in the subtree – do you know what purpose this serves?

      One reason IDs keep changing is because we are making changes to when they are assigned, and also changes that affect the order in which lifecycle components are created. Once the development effort settles the IDs should stabilize – however, I’d expect that the upcoming focus on DOM and component cleanup will continue to shake up recorded scripts.

      Mark

      From: Jerry Neal jkneal@iu.edu
      Sent: Wednesday, December 11, 2013 2:16 PM
      To: 'Mark Fyffe'
      Subject: RE: ids

      Hi Mark,

      Thanks for the information! I found the problem. It is due to the way I am running the lifecycle now for component refresh. The index on the phase was not the same and therefore I was getting different ids.

      I do think it would be good to consolidate the ID code. In fact, we might want to add the method to Component. We have been discussing IDs recently due to complaints from testers. The issue is, the IDs we are creating could change if a developer modifies the structure. Recorded scripts will grab these ids (if present), and then not work after updates. For things like inputs, it would be better if we didn’t have the Id on there, and selenium would use the name. However, we need the id in many cases. So we have been talking about how we can make these more static across updates. One approach is to use information from the component. For example, data/input fields have the property path which should be unique in most cases. Actions have the method to call, etc. So we might need different Id generation methods depending on the component. Does that make sense?

      Thanks,
      Jerry

      From: Mark Fyffe mark.w.fyffe@gmail.com
      Sent: Tuesday, December 10, 2013 3:43 PM
      To: Jerry Neal
      Subject: Re: ids

      There are three places now that generate IDs - each will produce a different ID but the results should be repeatable given the same set of circumstances. It will probably be best to consolidate these to a single utility - although it is not currently the case, path is available during the lifecycle, and within pre-process phase, so it should be possible to base all IDs on the path.
      ViewHelperServiceImpl.preprocessView() - Assigns IDs to all components involved in the initialize phase prior to caching the view. Uses path, class name, and parent component ids to maintain an evolving hash code as it traverses the tree. The results should be the same each time the same view is loaded and cached from the DD.
      AssignIdsTask - Assigns IDs during the initialize phase based on the class name and list position for all predecessor phases in the lifecycle phase tree. The results should be the same on each run as long as the components are processed in the same order. IDs are only assigned if not already present. This covers components dynamically created and spawned.
      ComponentUtils.generateAndAssignIds() - Used by LightTable and BreadcrumbOptions. IDs use an evolving hash based on class name and previously assigned ID. Current IDs are discarded and replaced with new values. Results should be repeatable as long as the components provided are consistent.
      In all cases, the ID generated is checked against a set maintained in ViewIndex to prevent duplicate IDs from being generated for the same view. If the ID has already been generated, it is considered a hash collision, so will be seeded again until an ID that hasn't been used for the current view is generated.
      Off the top of my head, I can't think of a reason why a component would get a new ID on refresh. I does seem possible, though, since ID assignment and manipulation takes place during performComponentLifecycle(). Do you have an example of where it is happening?
      Best,
      Mark

      On Tue, Dec 10, 2013 at 2:45 PM, Jerry Neal <jkneal@iu.edu> wrote:
      Hi Mark,

      The new Id generation strategy you put in is based on the component path correct? So if we refreshed a component, the id that gets generated should be the same correct? For some reason, I am not seeing this happen currently.

      Thanks,
      Jerry

        Activity

        Mark Fyffe (Inactive) made changes -
        Field Original Value New Value
        Remaining Estimate 4 hours [ 14400 ] 0 minutes [ 0 ]
        Time Spent 4 hours [ 14400 ]
        Worklog Id 91479 [ 91479 ]
        Mark Fyffe (Inactive) made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Complete [ 6 ]
        Mark Fyffe (Inactive) made changes -
        Resolution Complete [ 6 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Mark Fyffe (Inactive) made changes -
        Time Spent 4 hours [ 14400 ] 7 hours [ 25200 ]
        Worklog Id 91486 [ 91486 ]
        Mark Fyffe (Inactive) made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Mark Fyffe (Inactive) made changes -
        Time Spent 7 hours [ 25200 ] 1 day [ 28800 ]
        Worklog Id 92305 [ 92305 ]
        Mark Fyffe (Inactive) made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Mark Fyffe (Inactive) made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Eric Westfall made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Claus Niesen made changes -
        Fix Version/s Not version specific [ 17967 ]

          People

          • Assignee:
            Mark Fyffe (Inactive)
            Reporter:
            Jerry Neal (Inactive)
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 4 hours Original Estimate - 4 hours
              4h
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 1 day
              1d

                Structure Helper Panel