[
https://issues.apache.org/jira/browse/TAPESTRY-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514783
]
Kristian Marinkovic commented on TAPESTRY-1650:
-----------------------------------------------
hi howard, i want to use this tracking issue on ajax to share some of my
thoughts on tapestry 5 ajax (javascript) integration. I hope you find it useful
and other tapestry enthusiasts will comment on it :
1. T5 should not generate javascript that is specific to a certain javascript
library. instead T5 should generate a javascript array (or json object) that
is interpreted by a tapestry script that calls the specific javascript library
function calls. IMHO the integration of dojo into T4.1 was so tight that it
was almost impossible to switch without rewriting the components (jesse don't
get me wrong, you did a great job; i use EventListener all the time :)) For
example: ActionLink should trigger an ajax event. therefore it gets a mixin
(thats what i did:)) or (EventListener) annotation or whatever associated that
ensures that the component contains a unique id and stores it in a map. at the
end of the page render phase a javascript array with the ids of the annotated
components gets rendered. on page load (onLoad) a T5 script interprets the ids
and adds the necessary event listener (and everything else) using the
javascript library specific function calls. Adoption of another javascript
libraries would just require a small change in a javascript file.
2. T5 should use javascript event delegation wherever possible. by default all
events are registered onto the body node. if an event bubbles up a T5 script
gets started that first starts to find out which node caused the event. it does
so by reading the node's id and then matching it with the ids in the previously
generated javascript array. on a miss the parent node is checked ... and so on
up to the body node. if an adequate entry is found (id and event type) the
registered function/ajax call is called. i experienced situations in our T4
applications where an uncontrolled use of event listeners (think of a calendar
component placed multiple times on a page where every day node has an event
listener attached :)) or really big lists of input fields with event listeners
attached ... can cause considerable loss of performance on the client side.
event delegation would minimize the javascript complexity on the client side to
a minimum resulting in better performance (note: firefox will display the page
and pause any user interaction till every event listener is attached, ie6/7
will show nothing till every event listener is attached)
2.1. possibility to define an alternative/additional event delegate (maybe with
a separate annotation ... or just a parameter). so it should be possible to
have several javascript event delegates on a page for event grouping. i think
of a list of links generated in a loop whose events get processed by an
enclosing element.
3. integrate all the features of @EventListener from T4 : form, sync, async,
json support, component update.... :)
i hope i could express myself in a way everyone understands... please don't
forget: english is not my native language :)
> Tracking issue for Ajax support
> -------------------------------
>
> Key: TAPESTRY-1650
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1650
> Project: Tapestry
> Issue Type: New Feature
> Components: tapestry-core
> Affects Versions: 5.0
> Reporter: Howard M. Lewis Ship
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
