Uploaded image for project: 'Tapestry'
  1. Tapestry
  2. TAPESTRY-1408

Breakup @InitialValue functionality

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 4.1.2
    • 4.2
    • Annotations
    • None

    Description

      Currently, @InitialValue is responsible for initialize a property prior to use and reseting the property prior to returning the component or page to the pool.

      This has some negative aspects:

      1) If InitialValue specifies a non-null value, extra objects occupy memory.
      2) InitialValue cannot refer to anything that might result in a large graph of objects (for example a db query result) as this graph will remain after the processing is complete.
      3) @Persist("session") + @InitialValue() semantics are unclear.

      I propose that @InitialValue be modified so that it takes a second argument:

      @InitialValue(pre-use-value, reset-value)

      "pre-use-value" - assigned to the property prior to the first attempt to use the property.
      "reset-value" - assigned to the property prior to the component/page being returned to the pool ( default: null)

      InitialValue would be changed so that it acts the first time the property's get method is called, provided the property doesn't already have a value set by another annotation ( @Persist("session") ) or some other reason (tapestry experts fill in that some-other-reason here ). InitialValue would set the propert by using the property's set() method rather than setting it directly (I think this is what is done today)

      When the component/page is returned to the pool, the 'reset-value' would be used. When reseting the property, InitialValue should not use the property's set() method, but would set the field variable directly.

      What would this mean? This would eliminate many uses "prepareForRender()" methods. Also eliminated would be the if ( == null ) { } initialization boilerplate done in a property's get() . Both could be replaced by:

      @InitialValue("dataFromDB")
      // or @InitialValue("getDataFromDB()")
      public abstract MyData getData();

      protected MyData getDataFromDB() {
      // hard work here
      }

      In the html, the user would just refer to the 'data' property. If due to conditional blocks the 'data' property was never accessed, then getDataFromDB() is never called either.

      This would also allow @Persist + @InitialValue to work together. InitialValue does its thing when accessed and it would invoke the set() method on the property to trigger any session persistence.

      If there are backward compatability issues, could a new annotation be created?

      This change would help make initializing components/pages flow more naturally.

      Thanks....

      Attachments

        Activity

          People

            Unassigned Unassigned
            patmoore@ieee.org Patrick Moore
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: