OK i tried onClick (which didnt work) and onclick and that didnt work
with respect (but at least that permutation caused the serverside
event listener to be run) to the script fragment. I also modified the
.script to be
<?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>
alert('Gooo Team!' );
</initialization>
</script>
which also didnt work. I also tried modifying the server side event
listener to:
(im not sure if its the most inspired attempt, but it was worth a shot..)
DojoAjaxResponseBuilder builder= (DojoAjaxResponseBuilder
)getRequestCycle().getResponseBuilder();
builder.updateComponent("refreshme");
which also didnt make a difference...no alert() dialog or anything... :-(
Wait, does the code I sent work on your end? if so, what configuration
is it? (im deleting my maven repository for te org/apache/tapestry/*
folders as we speak to force a reload )
Thanks,
Josh
On 7/30/06, Jesse Kuhnert (JIRA) <[email protected]> wrote:
[
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]
