You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org> on 2009/10/27 22:34:59 UTC
[jira] Created: (TAP5-911) It is possible to have conflicts in
ordering of JavaScript initialization on the client-side
It is possible to have conflicts in ordering of JavaScript initialization on the client-side
--------------------------------------------------------------------------------------------
Key: TAP5-911
URL: https://issues.apache.org/jira/browse/TAP5-911
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.2.0.0
Reporter: Howard M. Lewis Ship
Priority: Minor
I occasionally have problems with the non-deterministic ordering of initialization on the client side. Because of how Tapestry groups together the RenderSupport.addInit() calls, you can't know in what order initialization functions may occur. For example, I've been working on a mixin to add a confirmation window to a link or submit (i.e., "do you really want to launch the missiles?") and that, of course, needs to be the FIRST click event handler, but there's no way (with Prototype) to enforce that.
Another option is to have the click handlers be very simple and simply fire a Tapestry specific event to do the actual work. You could then (in my use case) throw away the other click handlers, as long as the specific event handlers get triggered.
I've had a long term vision of a client-side-event-bus for these types of things. I'm actually getting envious of the ExtJs concept of client-side components as non-visiual components distinct from client-side elements (but still accessible via a unique id).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-911) It is possible to have conflicts in
ordering of JavaScript initialization on the client-side
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAP5-911.
-------------------------------------
Resolution: Duplicate
Assignee: Howard M. Lewis Ship
Duplicate of TAP5-774
> It is possible to have conflicts in ordering of JavaScript initialization on the client-side
> --------------------------------------------------------------------------------------------
>
> Key: TAP5-911
> URL: https://issues.apache.org/jira/browse/TAP5-911
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.2.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Priority: Minor
>
> I occasionally have problems with the non-deterministic ordering of initialization on the client side. Because of how Tapestry groups together the RenderSupport.addInit() calls, you can't know in what order initialization functions may occur. For example, I've been working on a mixin to add a confirmation window to a link or submit (i.e., "do you really want to launch the missiles?") and that, of course, needs to be the FIRST click event handler, but there's no way (with Prototype) to enforce that.
> Another option is to have the click handlers be very simple and simply fire a Tapestry specific event to do the actual work. You could then (in my use case) throw away the other click handlers, as long as the specific event handlers get triggered.
> I've had a long term vision of a client-side-event-bus for these types of things. I'm actually getting envious of the ExtJs concept of client-side components as non-visiual components distinct from client-side elements (but still accessible via a unique id).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-911) It is possible to have conflicts in
ordering of JavaScript initialization on the client-side
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAP5-911.
-------------------------------------
Resolution: Duplicate
Assignee: Howard M. Lewis Ship
Duplicate of TAP5-774
> It is possible to have conflicts in ordering of JavaScript initialization on the client-side
> --------------------------------------------------------------------------------------------
>
> Key: TAP5-911
> URL: https://issues.apache.org/jira/browse/TAP5-911
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.2.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Priority: Minor
>
> I occasionally have problems with the non-deterministic ordering of initialization on the client side. Because of how Tapestry groups together the RenderSupport.addInit() calls, you can't know in what order initialization functions may occur. For example, I've been working on a mixin to add a confirmation window to a link or submit (i.e., "do you really want to launch the missiles?") and that, of course, needs to be the FIRST click event handler, but there's no way (with Prototype) to enforce that.
> Another option is to have the click handlers be very simple and simply fire a Tapestry specific event to do the actual work. You could then (in my use case) throw away the other click handlers, as long as the specific event handlers get triggered.
> I've had a long term vision of a client-side-event-bus for these types of things. I'm actually getting envious of the ExtJs concept of client-side components as non-visiual components distinct from client-side elements (but still accessible via a unique id).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.