You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2012/04/30 18:58:03 UTC
Script Loaders, Modules, and other JS thoughts
I've been reviewing more options about handling dynamic loading of
JavaScript in 5.4.
Based on this talk at Strange Loop
(http://www.infoq.com/presentations/The-Once-And-Future-Script-Loader)
I'm now leaning towards LABjs (http://labjs.com/), rather than
RequireJS.
I like RequireJS's approach to modules (AMD), but they aren't getting
the right traction, with Bootstrap and Underscore actually removing
support for AMD.
I do want to craft an easy to use module system on top of LABjs, and
I'm brainstorming what that might look like. Perhaps it would borrow
from RequireJS and look something like:
T5.define([".../xyz.js", "..../pdq.js", "some/other/module"],
function(xyz, pdq, other) {
...
return <an object or function>
});
This would load xyz.js, pdq.js and some/other/module, and their
dependencies, in parallel. When all was loaded, the function would be
invoked. I'm not sure, what (if anything) would be passed for
JavaScript libraries. Again, with the AMD setup, a object named
module is placed in scope, and the "value" of the library is whatever
is assigned, by the library, to module.exports.
There might also be an option that would do the loading in parallel,
but implicitly wait for the the DOM to be loaded before invoking the
callback function.
This is very close to the AMD specification; maybe there should be a
T5.require() as well.
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.
I've also had some thoughts about a kind of "wrapper" that could be
used to adapt a third party module so that it could be used in the
module context:
#include "some-library.js"
module.exports = SOMELIB.noConflict();
In this wrapper mode, the library is included (as in a C language
#include) to form a new virtual script, which is executed; the wrapper
provides the extra logic to integrate the library into the module
system.
Another goal is to cleanly integrate CoffeeScript and Less and/or
SASS. This has already been done by third parties (I don't want to
look at their approach as it should be "clean room" for Apache).
Option A. The CS and Less support is built right into tapestry-core.
Advantage: easy way to use it ourselves: Disadvantage: tons of new
dependencies for tapestry-core.
Option B. The CS and Less support is an additional Apache module.
Advantage: dependency control for end users. Disadvantage: can't use
it in tapestry-core.
Option C. Static CS and Less support as part of tapestry-* build, on
top of option B. Advantage: we can use CS/Less in project.
Disadvantage: complicated build, need to do something to regenerate
when live coding the framework.
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.
--
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
Re: Script Loaders, Modules, and other JS thoughts
Posted by Howard Lewis Ship <hl...@gmail.com>.
Also, I didn't mention how I see the page working:
There will be a bootstrap phase, based on <script> tags. This will be
how LABjs is loaded.
There will be some additional bootstrap that will be used to define
the module system, whatever form that takes. Also, there may be some
bootstrap that exists to prevent early clicking (i.e., before the JS
for the page has loaded). That's something that really needs to be
revisited.
The initialization <script> block will expect that the module system
is available, and will work though that; page initialization will
change a bit.
Today we expect initialization in the form of T5.initializers;
libraries are loaded that add new initialization functions to this
namespace, and then we match initializer names (as names of properties
of T5.initializers) to initializer parameters.
One weakness of this system is that the developer must come up with a
name and location for their JS and for their initializer function
name, and @Import the JS in one place, and reference the initializer
function name in another. Further, there's the possibility of naming
conflicts as different third party libraries attempt to add their own
entries onto T5.initializers.
The importance of the module system is that, instead of referencing a
named function of T5.initializer, we'll reference a named function
defined by a named module, or just a named module (which will be
expected to export a single function).
Here's a bit more of an example:
OLD STYLE LIBRARY:
// app-inits.js:
T5.extendInitializers(function () {
...
return {
serverSideValidate : function(...) { ... },
setupLiveChange: function(...) { ... },
...
};
});
// Dynamic page initialization (i.e., via JavaScriptSupport):
T5.onDOMLoaded(function() {
T5.init({
serverSideValidate : [ ... ],
setupLiveChange : [ ... ],
...
});
});
In 5.3, the object passed to T5.init() is keys and values; keys are
names of T5.initializer functions, values are lists, each element in
the list is a single invocation of the initializer (i.e., the object,
or array of objects, passed to the function).
NEW STYLE MODULES:
// app/inits.js
T5.define([...], function(...) {
return {
serverSideValidate : function(...) { ... },
setupLiveChange: function(...) { ... },
...
};
});
// Dynamic page initialization
T5.onDOMLoaded(function() {
T5.init([
["app/inits", "serverSideValidate", [...]],
["app/inits", "setupLiveChange", [...]]
});
Note: the above represents a change to T5.init() where what's passed
is an array, rather than an object.
This initialization may appear to be a step backwards, as the
generated JS looks to be more verbose. However, it will allow the JS
to be refactored into smaller modules, each exporting a single
function, thus:
// Dynamic page initialization (refactored):
T5.onDOMLoaded(function() {
T5.init([
["app/inits/serverSideValidate", [...]],
["app/inits/setupLiveChange", [...]]
});
This refactoring will encourage developers to use smaller modules
(though they'll have interdependencies) and will eliminate the need to
name the function and avoid conflicts.
I also expect there'll be another form, where the value in the init is
just a module name, this will represent a module that needs to be
loaded for a global side effect: typically, to create global listeners
for events, which is common in modern (read: jQuery) apps.
That last note also indicates a direction to head in the future;
making use of HTML5 data- attributes and/or CSS class names so that
client ids are de-emphasized in favor of top-level event handler keyed
off of those class names and attributes.
I'm sorry this is a hurried discussion; must code for clients now.
On Mon, Apr 30, 2012 at 9:58 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I've been reviewing more options about handling dynamic loading of
> JavaScript in 5.4.
>
> Based on this talk at Strange Loop
> (http://www.infoq.com/presentations/The-Once-And-Future-Script-Loader)
> I'm now leaning towards LABjs (http://labjs.com/), rather than
> RequireJS.
>
> I like RequireJS's approach to modules (AMD), but they aren't getting
> the right traction, with Bootstrap and Underscore actually removing
> support for AMD.
>
> I do want to craft an easy to use module system on top of LABjs, and
> I'm brainstorming what that might look like. Perhaps it would borrow
> from RequireJS and look something like:
>
> T5.define([".../xyz.js", "..../pdq.js", "some/other/module"],
> function(xyz, pdq, other) {
>
> ...
>
> return <an object or function>
> });
>
> This would load xyz.js, pdq.js and some/other/module, and their
> dependencies, in parallel. When all was loaded, the function would be
> invoked. I'm not sure, what (if anything) would be passed for
> JavaScript libraries. Again, with the AMD setup, a object named
> module is placed in scope, and the "value" of the library is whatever
> is assigned, by the library, to module.exports.
>
> There might also be an option that would do the loading in parallel,
> but implicitly wait for the the DOM to be loaded before invoking the
> callback function.
>
> This is very close to the AMD specification; maybe there should be a
> T5.require() as well.
>
> 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.
>
> I've also had some thoughts about a kind of "wrapper" that could be
> used to adapt a third party module so that it could be used in the
> module context:
>
> #include "some-library.js"
> module.exports = SOMELIB.noConflict();
>
> In this wrapper mode, the library is included (as in a C language
> #include) to form a new virtual script, which is executed; the wrapper
> provides the extra logic to integrate the library into the module
> system.
>
> Another goal is to cleanly integrate CoffeeScript and Less and/or
> SASS. This has already been done by third parties (I don't want to
> look at their approach as it should be "clean room" for Apache).
>
> Option A. The CS and Less support is built right into tapestry-core.
> Advantage: easy way to use it ourselves: Disadvantage: tons of new
> dependencies for tapestry-core.
>
> Option B. The CS and Less support is an additional Apache module.
> Advantage: dependency control for end users. Disadvantage: can't use
> it in tapestry-core.
>
> Option C. Static CS and Less support as part of tapestry-* build, on
> top of option B. Advantage: we can use CS/Less in project.
> Disadvantage: complicated build, need to do something to regenerate
> when live coding the framework.
>
> 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.
>
> --
> 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
--
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
Re: Script Loaders, Modules, and other JS thoughts
Posted by trsvax <tr...@gmail.com>.
Sometimes it's nice just to include some existing jQuery script and use
without having to write a module/component.
The problem on Ajax calls is you may want to call it if there are elements
in the zone that need to be initialized. Perhaps on the page update it's
$('.zoneLink').init();
and on the zone update it's
$('#zoneId .zonelink').init();
Maybe
javascriptsupport.runOnce("('%s .zoneLink').init()", container);
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Script-Loaders-Modules-and-other-JS-thoughts-tp5676390p5681164.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Script Loaders, Modules, and other JS thoughts
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Wed, May 2, 2012 at 10:16 AM, yazdog8 <jo...@paulsenweb.com> wrote:
> Have you considered using http://zeptojs.com/ Zepto as your base? It's
> jQuery like, and easy to transition to full blown jQuery should you want,
> but not jQuery itself. And it's pretty light weight.
I would expect to include jQuery, but it will be configurable, and
possible to replace it with zepto. We could look at the zepto API and
try to only use things that are compatible with it.
My intentions in 5.4 is that a lot of the "optional" stuff, such as
animations, will simply be dropped; instead, there will be more DOM
events or pubsub messages to allow the developer greater control over
those visual aspects.
So, whether it is Prototype, jQuery, Zepto or any other, we primarily
need support for:
- DOM element selection & traversal
- DOM element creation / modification / removal
- DOM event listeners
- Ajax request support
Obviously, we could handle much of this using Sizzle (the CSS selector
engine) and XMLHttpRequest directly, but I'd rather leave as much of
the client stuff as possible with dedicated experts.
>
> As far as using data attributes, cracking open the JS that twitter bootstrap
> is producing has been eye opening for me, so much that most of the code my
> company is generating is based on what they're doing (listening at a body
> level for certain events triggered by DOM elements with certain data
> attributes). We now create widgets that are fired on the page just by having
> a certain data attribute (like bootstrap's data-toggle), pass URL's, pubsub
> locators, and various assorted extra information that you would normally
> have to build into a JSON object to pass over the wire.
>
Likewise; this concept ("unobtrusive JavaScript") has been around for
a while, but advances in HTML5 and jQuery have made it much more
reasonable. There's the definite advantage that putting a single event
handler function on the body tag means greater efficiency (one event
handler function, not dozens), less opportunity for memory leaks, and
much better resilience to DOM modifications, including partial page
renders.
> One thing I'd like to see is not binding pubsub to DOM elements and instead
> binding them to a global javascript object like Ben Alman does with his
> https://gist.github.com/661855 jQuery pubsub . At my place of work, we have
> the problem of DOM garbage collection in AJAX widgets. If we're dependent on
> zone updates or multiple zone updates, often we have no idea what zone is
> being fired if we're listening at a high (body) level. The pubsub events
> don't pass any reference event information along with the pubsub custom
> event, so we fly a bit blind. Instead of allowing widgets (flyouts, modals,
> etc) to be created in the body, we have to limit their creation to the zone.
> Allowing some kind of information to be passed so the listener can know that
> a specific DOM zone event was triggered (so we can initiate DOM
> cleanup/teardown) would be a very handy tool.
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/Script-Loaders-Modules-and-other-JS-thoughts-tp5676390p5681147.html
> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
--
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
Re: Script Loaders, Modules, and other JS thoughts
Posted by yazdog8 <jo...@paulsenweb.com>.
Have you considered using http://zeptojs.com/ Zepto as your base? It's
jQuery like, and easy to transition to full blown jQuery should you want,
but not jQuery itself. And it's pretty light weight.
As far as using data attributes, cracking open the JS that twitter bootstrap
is producing has been eye opening for me, so much that most of the code my
company is generating is based on what they're doing (listening at a body
level for certain events triggered by DOM elements with certain data
attributes). We now create widgets that are fired on the page just by having
a certain data attribute (like bootstrap's data-toggle), pass URL's, pubsub
locators, and various assorted extra information that you would normally
have to build into a JSON object to pass over the wire.
One thing I'd like to see is not binding pubsub to DOM elements and instead
binding them to a global javascript object like Ben Alman does with his
https://gist.github.com/661855 jQuery pubsub . At my place of work, we have
the problem of DOM garbage collection in AJAX widgets. If we're dependent on
zone updates or multiple zone updates, often we have no idea what zone is
being fired if we're listening at a high (body) level. The pubsub events
don't pass any reference event information along with the pubsub custom
event, so we fly a bit blind. Instead of allowing widgets (flyouts, modals,
etc) to be created in the body, we have to limit their creation to the zone.
Allowing some kind of information to be passed so the listener can know that
a specific DOM zone event was triggered (so we can initiate DOM
cleanup/teardown) would be a very handy tool.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Script-Loaders-Modules-and-other-JS-thoughts-tp5676390p5681147.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Script Loaders, Modules, and other JS thoughts
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Wed, May 2, 2012 at 8:47 AM, trsvax <tr...@gmail.com> wrote:
> One thing that would be helpful along with using data- would be the ability
> to run a script once. Perhaps something like:
>
> javascriptsupport.runOnce("('.zoneLink').init()");
>
> So no matter how many times you include the component you only get one init
> call.
That's something I've been struggling with ... its easy enough to
track such calls on the server during a single page render, but how do
you account for prior executions when you are doing an Ajax partial
page update? I suspect it involves more tracking on the client.
On the other hand, if that bit of logic was incorporated into a
module, you would get the just-once behavior for free, it would
probably look more like:
define(["core/jquery"], function($) {
$("body").on("click", ".zoneLink", ... );
});
On the server side, something like:
javaScriptSupport.module("core/zoneLink");
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/Script-Loaders-Modules-and-other-JS-thoughts-tp5676390p5680899.html
> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
--
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
Re: Script Loaders, Modules, and other JS thoughts
Posted by trsvax <tr...@gmail.com>.
One thing that would be helpful along with using data- would be the ability
to run a script once. Perhaps something like:
javascriptsupport.runOnce("('.zoneLink').init()");
So no matter how many times you include the component you only get one init
call.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Script-Loaders-Modules-and-other-JS-thoughts-tp5676390p5680899.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Script Loaders, Modules, and other JS thoughts
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <de...@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
Re: Script Loaders, Modules, and other JS thoughts
Posted by Denis Stepanov <de...@gmail.com>.
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.
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.
> // 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.
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
Re: Script Loaders, Modules, and other JS thoughts
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
Whatever you do do not name annotation @Data.
That would seriously conflict with project Lombok @Data annotation.
On May 2, 2012, at 9:32 AM, trsvax <tr...@gmail.com> wrote:
> I'm not in the lots of scripts/css fan club. While I think you can construct
> a benchmark that shows this to be faster the real world is much more
> complicated when you take into account caching. I also think CDNs are cheap
> enough that it does not make sense to load assets from the same web server
> as content. Large high volume sites will certainly use a CDN and small sites
> can just load things like jQuery from Google's CDN. I do think the default
> should be to load scripts asynchronously and my preference would be to have
> at most one per module.
>
> I also like the data- approach to parameters. It means the component does
> not really need to be involved in the parameter process since you can just
> put them in the page tml file and they get passed along. It might be nice if
> the component/mixin had access to them such as
>
> @Data
> private String zoneUpdateUrl;
>
> Next there are a couple of problems with tml files I'd like to see resolved.
>
> You can't really put JS functions in tml files and use zones because the
> zone response is JSON. it would be really nice to say
>
> <t:widget data-callback="function(a) {}"/>
>
> Related to this perhaps the p: parameters could be extended in a couple of
> ways.
>
> 1. It would be nice if they supports Maps so you could use them like this
>
> <t:widget>
> <p:map key="foo">
> value for map.get("foo");
> </p:map>
> </t:widget>
>
> 2. It would be nice it they could return a String so you could easily put
> things like css/scripts/templates in them. I'm OK with putting CDATA around
> non XML stuff. For example
>
> <t:layout>
> <p:css>
> p {
> page specific css
> }
> </p:css>
>
> <t:widget>
> <p:template>
> < ! [CDATA[
> non xml template stuff
> ]] >
> </p:template>
> <p:callback>
> function (a) {
> JS stuff
> }
> </p:callback>
> </t:widget>
> </t:layout>
>
> public class Widget {
> @Parameter
> private String template;
>
> @Paramter
> private String callback;
> }
>
>
> I think adding support for JS functions in the tml is a more useful feature
> than lots of JS files because it mostly does the same thing only better. For
> one thing it's in the template so I can put ${parm} inside them and secondly
> they get loaded with the main page so I don't need a 2nd ... nth request.
>
> Lastly it would be great to have support for ${selector:component} which
> returns a CSS selector to a component. I wrote one but it fails under
> certain circumstances. For example
>
> Easy:
> <t:widget id="abc">
> ${selector:abc}
>
> Harder:
> ${selector:abc}
> <t:widget id="abc">
>
> Hardest: //may no be worth solving
> ${selector:abc}
> <t:loop>
> <t:widget id="abc">
> </t:loop>
>
> Thanks
> Barry
>
>
>
>
>
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/Script-Loaders-Modules-and-other-JS-thoughts-tp5676390p5680534.html
> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Script Loaders, Modules, and other JS thoughts
Posted by trsvax <tr...@gmail.com>.
I'm not in the lots of scripts/css fan club. While I think you can construct
a benchmark that shows this to be faster the real world is much more
complicated when you take into account caching. I also think CDNs are cheap
enough that it does not make sense to load assets from the same web server
as content. Large high volume sites will certainly use a CDN and small sites
can just load things like jQuery from Google's CDN. I do think the default
should be to load scripts asynchronously and my preference would be to have
at most one per module.
I also like the data- approach to parameters. It means the component does
not really need to be involved in the parameter process since you can just
put them in the page tml file and they get passed along. It might be nice if
the component/mixin had access to them such as
@Data
private String zoneUpdateUrl;
Next there are a couple of problems with tml files I'd like to see resolved.
You can't really put JS functions in tml files and use zones because the
zone response is JSON. it would be really nice to say
<t:widget data-callback="function(a) {}"/>
Related to this perhaps the p: parameters could be extended in a couple of
ways.
1. It would be nice if they supports Maps so you could use them like this
<t:widget>
<p:map key="foo">
value for map.get("foo");
</p:map>
</t:widget>
2. It would be nice it they could return a String so you could easily put
things like css/scripts/templates in them. I'm OK with putting CDATA around
non XML stuff. For example
<t:layout>
<p:css>
p {
page specific css
}
</p:css>
<t:widget>
<p:template>
< ! [CDATA[
non xml template stuff
]] >
</p:template>
<p:callback>
function (a) {
JS stuff
}
</p:callback>
</t:widget>
</t:layout>
public class Widget {
@Parameter
private String template;
@Paramter
private String callback;
}
I think adding support for JS functions in the tml is a more useful feature
than lots of JS files because it mostly does the same thing only better. For
one thing it's in the template so I can put ${parm} inside them and secondly
they get loaded with the main page so I don't need a 2nd ... nth request.
Lastly it would be great to have support for ${selector:component} which
returns a CSS selector to a component. I wrote one but it fails under
certain circumstances. For example
Easy:
<t:widget id="abc">
${selector:abc}
Harder:
${selector:abc}
<t:widget id="abc">
Hardest: //may no be worth solving
${selector:abc}
<t:loop>
<t:widget id="abc">
</t:loop>
Thanks
Barry
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Script-Loaders-Modules-and-other-JS-thoughts-tp5676390p5680534.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Script Loaders, Modules, and other JS thoughts
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Wed, May 2, 2012 at 1:22 AM, Ulrich Stärk <ul...@spielviel.de> wrote:
> On 30.04.2012 18:58, Howard Lewis Ship wrote:
>> Another goal is to cleanly integrate CoffeeScript and Less and/or
>> SASS. This has already been done by third parties (I don't want to
>> look at their approach as it should be "clean room" for Apache).
>>
>> Option A. The CS and Less support is built right into tapestry-core.
>> Advantage: easy way to use it ourselves: Disadvantage: tons of new
>> dependencies for tapestry-core.
>
> CoffeeScript, Less and SASS all are under an MIT license and - according to [1] may be included in
> Apache products. My understanding is that we don't need to have them as external dependencies but
> may ship them directly with Tapestry. To be sure we could raise an issue with legal. That's what
> they are for.
That's good to know ... I was thinking about this from more of a "code
bloat" (really, "dependency bloat") angle.
>
> [1] http://www.apache.org/legal/resolved.html#category-a
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
--
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
Re: Script Loaders, Modules, and other JS thoughts
Posted by Ulrich Stärk <ul...@spielviel.de>.
On 30.04.2012 18:58, Howard Lewis Ship wrote:
> Another goal is to cleanly integrate CoffeeScript and Less and/or
> SASS. This has already been done by third parties (I don't want to
> look at their approach as it should be "clean room" for Apache).
>
> Option A. The CS and Less support is built right into tapestry-core.
> Advantage: easy way to use it ourselves: Disadvantage: tons of new
> dependencies for tapestry-core.
CoffeeScript, Less and SASS all are under an MIT license and - according to [1] may be included in
Apache products. My understanding is that we don't need to have them as external dependencies but
may ship them directly with Tapestry. To be sure we could raise an issue with legal. That's what
they are for.
[1] http://www.apache.org/legal/resolved.html#category-a
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org