tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: Script Loaders, Modules, and other JS thoughts
Date Wed, 02 May 2012 15:10:10 GMT
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 <denis.stepanov@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Mime
View raw message