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