[jira] Commented: (TAPESTRY-1408) Breakup @InitialValue functionality

["Ron Piterman (JIRA)" <de...@tapestry.apache.org>]

    [ https://issues.apache.org/jira/browse/TAPESTRY-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487888 ] 

Ron Piterman commented on TAPESTRY-1408:
----------------------------------------

IMO the reset value is obsolete. Why would one want to set a property to something else than null when the component is in the pool?

I did suggest adding a cycle argument to the @InitialValue annotation to allow one to choose between initializing on pageValidate (which is the behaiviour today) and  lazy initialization ( on first access ) - 

a third option could be added, similar to beans: the render cycle, thus, the property could be reset just after a component renders then it will be lazy intialized on the next access.

see https://issues.apache.org/jira/browse/TAPESTRY-856


Cheers,
Ron



> Breakup @InitialValue functionality
> -----------------------------------
>
>                 Key: TAPESTRY-1408
>                 URL: https://issues.apache.org/jira/browse/TAPESTRY-1408
>             Project: Tapestry
>          Issue Type: Improvement
>          Components: Annotations
>    Affects Versions: 4.1.2
>            Reporter: Patrick Moore
>
> 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....

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org