On Fri, Jul 13, 2012 at 11:36 AM, Howard Lewis Ship <[email protected]> wrote: > Earlier versions of Tapestry tried to track versions of each library > separately; you had to contribute a LibraryMapping to > ComponentClassResourceResolver, and contribute a seperate value to > ClasspathAssetAliasManager that included your version number. That > was a lot of work and was error prone, which is why 5.2 switched to > the one-version-number-to-rule-them-all. > > The upcoming module stuff will make version numbers even more > important. I don't see a viable middle ground currently, though > that's short of saying it is impossible. Perhaps there's a way that we > could define an optional library version number, that would default to > the application version number. > > On the other hand, I expect that 5.4 will be much "lighter" in its use > of JavaScript as the use of stand-alone libraries & stacks will start > to switch over to modules, which are loaded in parallel and as needed. > By 5.5, stacks and libraries should be the rare exception, and > modules the main approach. > > I'm still working on many of the details, including whether and how to > aggregate modules into stacks for efficient preloading. > > As a side note, I expect that by 5.5 we'll require that all classpath > assets made visible to the user be moved from the main class path to > folders under META-INF/assets. I.e., > "com/example/foolib/components/MyLib.js". I'm not quite sure what the > folder structure will be; possibly just parallel packages, just rooted > under META-INF/assets/ instead of /. >
BTW this is for two reasons - security - ability to enumerate the possible assets, for a CDN > > > On Fri, Jul 13, 2012 at 11:17 AM, Thiago H de Paula Figueiredo > <[email protected]> wrote: >> Sounds good to me. >> >> >>> >>> >>> >>> On Jul 13, 2012, at 1:16 PM, Kalle Korhonen <[email protected]> >>> wrote: >>> >>>> We are deploying our app to production once a week and I find it quite >>>> annoying that every time we basically force our users to re-download >>>> all of the application resources even though only a small subset of >>>> them changed, causing wasted bandwidth and perceived performance >>>> issues. At the same time, we cannot afford users to have stale >>>> resources in their caches. All of the Tynamo.org modules add their own >>>> version to asset paths so adding the application version is completely >>>> redundant, for example: >>>> >>>> http://localhost:8080/assets/0.0.1-SNAPSHOT-1341940822046/facebook-0.1.0/components/fb-button.css >>>> >>>> We briefly looked into generically changing how asset paths are >>>> constructed to include module's own version but it's difficult to >>>> achieve because the context (from which module the asset came) is >>>> lost. >>>> >>>> Tynamo modules contribute something like: >>>> public static void >>>> contributeClasspathAssetAliasManager(MappedConfiguration<String, >>>> String> configuration) >>>> { >>>> configuration.add(PATH_PREFIX + "-" + version, >>>> "org/tynamo/security"); >>>> } >>>> >>>> What if we implemented a ClassPathAssetAliasManager2 that would take a >>>> MappedConfiguration<String, Package> so we could automatically do the >>>> same as above for add-on modules, using >>>> Package.getImplementationVersion()? >>>> >>>> It would encourage the (best) practice of placing the main module >>>> class to the intended root package of a module, and it'd be very >>>> simple to contribute in the module like so: >>>> public static void >>>> contributeClasspathAssetAliasManager2(MappedConfiguration<String, >>>> Package> configuration) >>>> { >>>> configuration.add(PATH_PREFIX, getClass().getPackage() ); >>>> } >>>> >>>> Similarly, LibraryMapping (a contribution to ComponentClassResolver) >>>> could also accept a Package, rather than just a string. >>>> >>>> What do you think? >>>> >>>> Kalle >>>> >>>> --------------------------------------------------------------------- >>>> 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] >>> >> >> >> -- >> Thiago H. de Paula Figueiredo >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > 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: [email protected] For additional commands, e-mail: [email protected]
