[ http://issues.apache.org/jira/browse/TAPESTRY-1031?page=comments#action_12424440 ] Jesse Kuhnert commented on TAPESTRY-1031: -----------------------------------------
If you extend IWidget Tapestry should automatically make sure that your widget parameters are synced up for you with your corresponding widget. (http://tapestry.apache.org/tapestry4.1/tapestry-framework/apidocs/org/apache/tapestry/dojo/IWidget.html) This part is a little less thought out. If your widget doesn't already exist then yes, it would be instantiated and parsed properly (assuming you pass parameters via JSON bindings, as the DropDownDatePicker/Autocomplete components do). I haven't figured out a way to "update" widget properties globally. (because some widgets don't handle this the way they should) If the script fragment you referenced doesn't seem to be working I would try two things: -) change the events="onclick" to events="onClick" (just for tryings sake). The events parameter isn't changed/checked at all, it is passed directly to a dojo.event.connect(<foo>, event, etc..) call as-is..If you can get it work that way then it should work with events="" -) Try taking out the xml escape characters. (Just in case) I'm not saying the API shouldn't change/be enhanced to make these things easier, just suggestions to get you past whatever point you are at. (As well as confirming what the desired/expected behaviour was vs what really happened.) > 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]
