[ http://issues.apache.org/jira/browse/TAPESTRY-1031?page=all ]
Jesse Kuhnert resolved TAPESTRY-1031.
-------------------------------------
Fix Version/s: 4.1.1
Resolution: Fixed
Added additional logic to properly capture initialization/element target
listeners.
Your script logic should "just work" when I deploy the new snapshot.
> theres no javascript lifecycle for components rendered using the ajax rewind.
> -----------------------------------------------------------------------------
>
> Key: TAPESTRY-1031
> URL: http://issues.apache.org/jira/browse/TAPESTRY-1031
> Project: Tapestry
> Issue Type: Improvement
> Affects Versions: 4.1
> Environment: windows xp, maven 2, tapestry 4.1 snapshots, 2gb ram,
> ie/firefox
> Reporter: Joshua Long
> Assigned To: Jesse Kuhnert
> Fix For: 4.1.1
>
>
> I might be missing something, but..
> A component gets a guarantee of proper initialization because the javascript
> (typically employed through the Script component) gets a chance to intialize
> in the <initialization> block of a .script file for a standard
> request/response cycle, ie, window.onload.
> Making use of the EventListener annotation reveals a new problem: components
> rendered for the first time during the render cycle from an ajax request dont
> get that same guarantee, whcih effectively makes a lot of components non ajax
> freindly (think javascript heavy components like fck editor or even
> tapestry's pallette component) by default even if they dont need to be.
> Suggested remedies are:
> 1. extend the initialization block to all components even if theyre rendered
> dynamically. if youve contributed code to the initialization block of a
> script file then it should be invoked for any component rendered in an ajax
> request. This approach might break code that for some reason or another does
> things which can only work during onload and not afterwards. I cant imagine
> such a situation.. if youre setting properties on newly created objects or
> connecting even listeners or even adding nodes to something that should all
> be equally applicable to objects created before onload as objects created
> after a tags innerHTML has been updated through AJAX.
> 2. if however the above approach might theoretically break existing
> components, an even simpler solution (a pain in the arse, and it would render
> any useful components a company might have non -useful for ajax until its
> updated...), but sitll definitely doable is to modify te .script file and its
> DTD to honor a new section (something like <ajax-initialization>
> </ajax-initialization>)
> I prefer the first approach as it would transparently make all components and
> their embedded .script files useful in an ajax context. The second approach
> would be OK I suppose, but would fragment the component "market" needlessly
> into an even bigger schizm: tap3, tap4, tap4 + ajax.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
