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]
