Certainly, if you can follow my scattered thoughts and blog postings on this, I think we are headed in the same direction ... except for a direct dependence on jQuery. It would certainly be easier to just say "we use jQuery now ... go recode your components."
I'm definitely in favor of using data- attributes in preference, where possible, to today's approach: that is, generate an id on the element, then a JSONObject of configuration passed to a T5.initializers function. The goal would be that most components could work with just data- attributes, using handler on the body that catches the bubbled-up events, which is not only common in the jQuery world, but more efficient in the browser. Part of the module and packaging system, as I envision it, would be that modules could be part of stacks in production ... pre-compiled, compressed, and delivered to the browser in a single bundle. There might be configuration to describe which modules should be bundled. Lesser used components may keep their modules outside of the bundle. On Wed, May 2, 2012 at 4:37 AM, Denis Stepanov <[email protected]> wrote: > > Honestly, I'm not convinced about modules, Tapestry doesn't have so much > javascript to benefit from parallel/lazy script loading suggested in the > presentation, one minified file should be faster. > > I like the idea of separating tapestry.js into more files: ZoneManager, > Effects, Validation, Form etc. > >> Part of the overall goal here is to de-emphasize and eventually >> deprecate T5.initializers, and instead, make it easy to include a >> per-page or per-component JavaScript. > > Initializers could be removed and replaced by jquery's "on" event handlers > and attaching required parameters to the element using html5 custom data > attribute "data-": > > <a href="#" class="zoneLink" data-zone-update-url="..." data-zone="myZone" > data-zone-effect="someeffect">... > > dom.on 'click', '.zoneLink', -> > zoneId = $.data this, 'zone' > zone = T.ZoneManager.getOrFindAndCreateZone zoneId > url = $.data this, 'zone-update-url' > ... > >> I'd prefer A or C. C is more work, but may be the correct answer; for >> example, think what a disaster tapestry-yuicompressor would have been >> if it was built right into tapestry-core. > > > Rhino is not so fast right now, with big coffee files it could take minutes > to compile. I'm using it in my CoffeeScript plugin for NetBeans > https://github.com/dstepanov/coffeescript-netbeans. That's interesting and surprising! Having an option to precompile using Gradle will be important; as will, perhaps, an option to start a subprocess to let the native coffee command do the compilation. Part of my intention is that modules are just a name: a virtual folder ("core/", "app/", or supplied by a third party library, e.g., "tapx/") followed by a path, i.e., "components/Zone" ... then Tapestry would look for Zone.coffee or Zone.js until it found a match. Who knows? In some time, someone may have another transpiling language for JavaScript that will displace or complement CoffeeScript. > > Why not to have precompiled files and the support to use native less and > coffee files? Tapestry will have core coffee and less files precompiled, but > there be an option to use live files while developing or testing. Some > application servers have crippled Rhino and it is why yuicompressor doesn't > work for someone and it could be a problem if there was no precompiled files. This is a good point ... we often do things in the framework to improve efficiency in applications, so having Tapestry pre-compile its CoffeeScript as part of the build process would eliminate that step from production apps. > >> // Dynamic page initialization (refactored): >> >> T5.onDOMLoaded(function() { >> T5.init([ >> ["app/inits/serverSideValidate", [...]], >> ["app/inits/setupLiveChange", [...]] >> }); > > Why does it need to wait for DOM? The Init function can wait for dom. > Tapestry currently does initialization in up to four steps: IMMEDIATE, EARLY, NORMAL, and LATE. IMMEDIATE doesn't wait for the DOM to load, but is used quite rarely. The others occur in order after the DOM is loaded. > I don't really understand all that about modules and dynamic initialization, > I would write static jquery-plugin-like initilization: > > T5.init.linkZone = (spec) -> > > modules("zone").linkZone(spec) > > > Denis > Thanks for the feedback! -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
