[CONF] Apache Tapestry Client-Side JavaScript
Howard M. Lewis Ship edited the page: Client-Side _javascript_ ... The result is a a bit schizophrenic; it mostly looks like jQuery, but events look a bit more like jQueryPrototype. It also doesn't have jQuery's concept of operating on a matched set of elements. The abstraction is both transitional and permanent. It is transitional in that it is about allowing existing sites with a heavy investment in Prototype to continue to operate with Prototype in the mix. It is permanent in in that it is desirable for third party library developers to keep an abstraction layer between Tapestry's client-side code and any underlying framework, so that particular applications can provide their own abstraction layer and operate without breaking built-in components. ... View Online Like View Changes Stop watching space Manage Notifications This message was sent by Atlassian Confluence 5.0.3, Team Collaboration Software
[CONF] Apache Tapestry Client-Side JavaScript
Howard M. Lewis Ship edited the page: Client-Side _javascript_ ... This is more of a full lifecycle approach; there's no danger of adding or removing page content (such as with aZone component) is both cheaper and less error prone using top-level event handlers than per-element event handlers; there's also less of a chance of memory leaks under Internet Explorer. Note Internet Explorer is pretty well known for memory leaks; its DOM and _javascript_ run in different kinds of memory, which are garbage collected individually. This means that a reference from _javascript_ to a DOM element will keep the DOM element live, even if that's the only reference to the DOM element anywhere. Meanwhile, event handler _javascript_ functions are kept live from the DOM element, making a cycle that can't be broken. Libraries like Prototype and jQuery have to expend some effort to break this link by unregistering event handlers from DOM elements when removing them from the DOM. A specific example of this approach is how client-side validation now works; in the past, there was a complex system of classes and event listeners that were specific to each individual field. Field controllers had to register with Form controllers. Validators had to register with Field controllers. Under 5.4, there are a number ofdata- attributes that can be attached to any DOM element. A form will search for elements with a non-blank value fordata-validation; each such element has a series of custom events triggered on it. The top-level handlers for those events will receive notifications for elements throughout the document. Code Block title t5/core/validation.coffee (partial)
[CONF] Apache Tapestry Client-Side JavaScript
Howard M. Lewis Ship edited the page: Client-Side _javascript_ ... A different event is triggered after the optionality check; Thememo.translated property is the value translated before validation (for a numeric field, it would be translated from a string to a number, for example). Again, theerror property is set, and thereturn false ensures that the event will stop bubbling to containing elements or event handlers. What's very useful in this overall approach is that it no longer matters whether the fields were rendered by Tapestry on the server, or rendered locally (perhaps using Backbone or AngularJS) on the client. As long as they have the correctdata- attributes, then they can participate in Tapestry's overall form validation and submission cycle, and even leverage the default validation decoration behavior. The Abstraction Layer The abstraction layer is defined by thet5/core/dom module. This module is two different implementations - one is a wrapper around Prototype, and the other is a wrapper around jQuery. The result is a a bit schizophrenic; it mostly looks like jQuery, but events look a bit more like jQuery. It also doesn't have jQuery's concept of a matched set of elements. The abstraction is both transitional and permanent. It is transitional in that it is about allowing existing sites with a heavy investment in Prototype to continue to operate with Prototype in the mix. It is permanent in that it is desirable to keep an abstraction layer between Tapestry's client-side code and any underlying framework, so that particular applications can provide their own abstraction layer and operate without breaking built-in components. Most applications should transition to jQuery and feel free to use jQuery directly. It is still best to inject module jqueryinto your own modules (usually as parameter$). If you are writing a third-party application and want to maximize re-use, then use the abstraction. It is often easier to use the abstraction to respond correctly to View Online Like View Changes Stop watching space Manage Notifications This message was sent by Atlassian Confluence 5.0.3, Team Collaboration Software
[CONF] Apache Tapestry Client-Side JavaScript
Howard M. Lewis Ship edited the page: Client-Side _javascript_ ... It is often easier to use the abstraction to respond correctly toto custom Tapestry events. View Online Like View Changes Stop watching space Manage Notifications This message was sent by Atlassian Confluence 5.0.3, Team Collaboration Software
