You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Joshua Long (JIRA)" <ta...@jakarta.apache.org> on 2006/07/30 22:31:13 UTC
[jira] Created: (TAPESTRY-1031) theres no javascript lifecycle for
components rendered using the ajax rewind.
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
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-1031) theres no javascript lifecycle
for components rendered using the ajax rewind.
Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-1031?page=comments#action_12424435 ]
Jesse Kuhnert commented on TAPESTRY-1031:
-----------------------------------------
Are you sure about that? I thought I had specifically addressed this inside DojoAjaxResponseBuilder.
If you have a block inside a Script template that relies on initialization functionality it should work regardless of whether it's a normal http or AJAX request. Each request type should be handling this functionality in a very specific way to make it transparent when writing the Script template.
Are you not seeing this happen?
> 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
>
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Resolved: (TAPESTRY-1031) theres no javascript lifecycle for
components rendered using the ajax rewind.
Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
[ 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-1031) theres no javascript lifecycle
for components rendered using the ajax rewind.
Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-1031?page=comments#action_12424436 ]
Jesse Kuhnert commented on TAPESTRY-1031:
-----------------------------------------
P.S. Either way I should probably document this new behaviour.
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-1031) theres no javascript lifecycle
for components rendered using the ajax rewind.
Posted by "Joshua Long (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-1031?page=comments#action_12424438 ]
Joshua Long commented on TAPESTRY-1031:
---------------------------------------
Well, it's good to see you already thought of this ;-) I like it when its already been thought of but not working quite as I expected.
A propsito, does that also mean any dojo components inside of an ajax request will also be reparsed by dojo or is that asking for too much ;-)
The example I have is:
<pre>
<span jwcid="@Shell" title=" foo 0.1" ajaxEnabled="true" browserLogLevel="DEBUG">
<body jwcid="@Body">
<span jwcid="@Script" script="scripts/Test.script">
invoke the script
</span>
<!-- that just proves that the js will run in a normal cycle, onload -->
<form jwcid="f@Form" action="">
<div id="mLink" style="background-color: yellow; width:100px;">
click me to activate my script
</div>
<div jwcid="refreshme@Any">
<span jwcid="@If" condition="ognl:good">
<span jwcid="@Insert" value="ognl: message"> the msg goes here </span>
<span jwcid="@Script" script="scripts/Test.script"> </span>
</span>
</div>
</form>
</body>
</span>
</pre>
with the java code:
<pre>
import org.apache.tapestry.IRequestCycle;
import org.apache.tapestry.annotations.EventListener;
import org.apache.tapestry.annotations.Persist;
import org.apache.tapestry.event.BrowserEvent;
import org.apache.tapestry.html.BasePage;
import java.text.MessageFormat;
abstract public class Playground extends BasePage {
abstract public boolean isGood();
abstract public void setGood(boolean good);
@Persist
abstract public String getMessage();
abstract public void setMessage(String message);
@EventListener(events = "onclick", submitForm = "f", elements = "mLink")
public void handleUpdatingThingsAreGood(IRequestCycle c) {
BrowserEvent event = new BrowserEvent(c);
setGood(true);
setMessage("base page moo cow " + new java.util.Date());
System.out.println("things are good = true");
System.out.println(MessageFormat.format("x = {0}, y={1}", event.getPageX(), event.getPageY()));
getRequestCycle().getResponseBuilder().updateComponent("refreshme");
}
}
</pre>
and the .script file of :
<?xml version="1.0"?>
<!DOCTYPE script PUBLIC
"-//Apache Software Foundation//Tapestry Script Specification 3.0//EN"
"http://jakarta.apache.org/tapestry/dtd/Script_3_0.dtd">
<script>
<initialization>
<![CDATA[
alert('Gooo Team!' );
]]>
</initialization>
</script>
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-1031) theres no javascript lifecycle
for components rendered using the ajax rewind.
Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
[ 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-1031) theres no javascript lifecycle
for components rendered using the ajax rewind.
Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-1031?page=comments#action_12424468 ]
Jesse Kuhnert commented on TAPESTRY-1031:
-----------------------------------------
I see what you mean. I'll try and create a fix tonight, but if not definitely by tomorrow. Note that when the fix is made you'll have to upgrade to the new 4.1.1-SNAPSHOT version.
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-1031) theres no javascript lifecycle
for components rendered using the ajax rewind.
Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
[ 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Assigned: (TAPESTRY-1031) theres no javascript lifecycle for
components rendered using the ajax rewind.
Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-1031?page=all ]
Jesse Kuhnert reassigned TAPESTRY-1031:
---------------------------------------
Assignee: Jesse Kuhnert
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org