[
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="[EMAIL PROTECTED]" action="">
<div id="mLink" style="background-color: yellow; width:100px;">
click me to activate my script
</div>
<div jwcid="[EMAIL PROTECTED]">
<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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
