[ http://issues.apache.org/jira/browse/TAPESTRY-1031?page=comments#action_12424574 ] Jesse Kuhnert commented on TAPESTRY-1031: -----------------------------------------
I have it fixed and working now Josh, just can't commit the changes quite yet. You exposed the need for a much more extensive change than I had anticipated (a good change though). Once I get done adjusting/adding more unit tests to be sure I'm not screwing everything up I'll commit and update this ticket. People should be happy to finally have a working parent/child IComponent heirachy to play with at least :) > 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 > > 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]
