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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to