You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by bu...@apache.org on 2014/07/18 01:19:36 UTC
svn commit: r916589 - in /websites/production/tapestry/content:
cache/main.pageCache client-side-javascript.html
Author: buildbot
Date: Thu Jul 17 23:19:35 2014
New Revision: 916589
Log:
Production update by buildbot for tapestry
Modified:
websites/production/tapestry/content/cache/main.pageCache
websites/production/tapestry/content/client-side-javascript.html
Modified: websites/production/tapestry/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/tapestry/content/client-side-javascript.html
==============================================================================
--- websites/production/tapestry/content/client-side-javascript.html (original)
+++ websites/production/tapestry/content/client-side-javascript.html Thu Jul 17 23:19:35 2014
@@ -94,7 +94,7 @@
if memo.translated.length < min
memo.error = (@attr "data-min-length-message") or "TOO SHORT"
return false]]></script>
-</div></div><p>The <code>t5/core/events</code> module defines constants for different custom event name, it's also a handy place to hang <a shape="rect" class="external-link" href="http://tapestry.apache.org/5.4/coffeescript/events.html">hang documentation</a> about those events.</p><p>The <code>t5/core/dom</code> namespace is the abstraction layer.  <code>onDocument</code> is a handy way to attach a top-level event handler.</p><p>Fields that are required will have the attribute <code>data-optionality=required</code>; the event handler is passed a <em>memo</em> object that includes a <code>value</code> property, the value from the field. This makes it easier to generate an error if the value is blank.  Because the exact error message may be customized or localized, it is provided in the element as well, as the <code>data-required-message</code> attribute. Setting <code>memo.error</code> to a validation error string will cause the fie
ld to be decorated with the error message and will indicate that the form itself is in error and not ready for submission.</p><p>A different event is triggered after the optionality check; The <code>memo.translated</code> property is the value translated before validation (for a numeric field, it would be translated from a string to a number, for example). Again, the <code>error</code> property is set, and the <code>return false</code> ensures that the event will stop bubbling to containing elements or event handlers.</p><p>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 correct <code>data-</code> attributes, then they can participate in Tapestry's overall form validation and submission cycle, and even leverage the default validation decoration behavior.</p><h3 id="Client-SideJavaScr
ipt-TheAbstractionLayer">The Abstraction Layer</h3><p>The abstraction layer is defined by the <code>t5/core/dom</code> module. This module is two different implementations - one is a wrapper around Prototype, and the other is a wrapper around jQuery.</p><p>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.</p><p>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.</p><p>Most applications should transition to jQuery and feel free to use jQuery directly.  
It is still best to inject module <span style="font-family: monospace;">jquery</span> into your own modules (usually as parameter <code>$</code>). </p><p>If you are writing a third-party application and want to maximize re-use, then use the abstraction.</p><p>It is often easier to use the abstraction to respond correctly to custom Tapestry events.</p></div>
+</div></div><p>The <code>t5/core/events</code> module defines constants for different custom event name, it's also a handy place to hang <a shape="rect" class="external-link" href="http://tapestry.apache.org/5.4/coffeescript/events.html">hang documentation</a> about those events.</p><p>The <code>t5/core/dom</code> namespace is the abstraction layer.  <code>onDocument</code> is a handy way to attach a top-level event handler.</p><p>Fields that are required will have the attribute <code>data-optionality=required</code>; the event handler is passed a <em>memo</em> object that includes a <code>value</code> property, the value from the field. This makes it easier to generate an error if the value is blank.  Because the exact error message may be customized or localized, it is provided in the element as well, as the <code>data-required-message</code> attribute. Setting <code>memo.error</code> to a validation error string will cause the fie
ld to be decorated with the error message and will indicate that the form itself is in error and not ready for submission.</p><p>A different event is triggered after the optionality check; The <code>memo.translated</code> property is the value translated before validation (for a numeric field, it would be translated from a string to a number, for example). Again, the <code>error</code> property is set, and the <code>return false</code> ensures that the event will stop bubbling to containing elements or event handlers.</p><p>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 correct <code>data-</code> attributes, then they can participate in Tapestry's overall form validation and submission cycle, and even leverage the default validation decoration behavior.</p><h3 id="Client-SideJavaScr
ipt-TheAbstractionLayer">The Abstraction Layer</h3><p>The abstraction layer is defined by the <code>t5/core/dom</code> module. This module is two different implementations - one is a wrapper around Prototype, and the other is a wrapper around jQuery.</p><p>The result is a a bit schizophrenic; it mostly looks like jQuery, but events look a bit more like Prototype. It also doesn't have jQuery's concept of operating on a matched set of elements.</p><p>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 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.</p><p>Most applications should transiti
on to jQuery and feel free to use jQuery directly.  It is still best to inject module <span style="font-family: monospace;">jquery</span> into your own modules (usually as parameter <code>$</code>). </p><p>If you are writing a third-party application and want to maximize re-use, then use the abstraction.</p><p>It is often easier to use the abstraction to respond correctly to custom Tapestry events.</p></div>
</div>
<div class="clearer"></div>