Mailing-List: contact dev-help@tapestry.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tapestry development" <dev@tapestry.apache.org>
Received-SPF: pass (athena.apache.org: domain of hlship@gmail.com designates
 74.125.82.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A2987CC4-2550-4B27-981A-B2139068FEDB@hope.nyc.ny.us>
References: 
 <CA+=EWnCFtTrVOwKd0x_L3uyQqUbzqxaFb4cVmRr9iEMhKzXTiw@mail.gmail.com>
	<F3B389BA-3DB2-4902-8344-3A7AD450782D@hope.nyc.ny.us>
	<op.whec2pzuovlrp5@shire.ifactory.com>
	<CACd-vsOELBFFBrs-b=8rXoMY4j1V=qsfzF9XTAQVq1vsfdwf6Q@mail.gmail.com>
	<A2987CC4-2550-4B27-981A-B2139068FEDB@hope.nyc.ny.us>
Date: Sun, 22 Jul 2012 11:28:39 -0700
Message-ID: 
 <CACd-vsPBNtAiAf7rRpk4jz=kB3qT2O4PdxAGzs2XBmnt3kgJTg@mail.gmail.com>
Subject: Re: Module-specific versioning of assets?
From: Howard Lewis Ship <hlship@gmail.com>
To: Tapestry development <dev@tapestry.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

One of the advantages of the single version number as implemented in
5.3, is that (from the client's point of view) the hierachy of assets
is simple and predictable.

I've leveraged this in the past to have a CSS in a library use a
../core relative URL to access an asset packaged with the core
framework.

If every module has its own version number, that kind of relative url
(rare but useful) would no longer be possible, since it would have to
be ../../123abc/core  (where "123abc" is the core version number, and
not statically predictable).

This may not be a big issue however; I've been thinking about how to
aggregate CSS as we do JS; the first step there is to expand all url()
references to absolute paths anyway.

On Fri, Jul 13, 2012 at 4:39 PM, Lenny Primak <lprimak@hope.nyc.ny.us> wrote:
> I like the optional version number idea. I don't think it's impossible to track asset versions by module.
> You could make it a dual alias, I.e. both referenceable by the application version and by module version. It can be a bit more flexible without any sacrifices.
>
>
>
> On Jul 13, 2012, at 2:36 PM, Howard Lewis Ship <hlship@gmail.com> 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 /.
>>
>>
>>
>> On Fri, Jul 13, 2012 at 11:17 AM, Thiago H de Paula Figueiredo
>> <thiagohp@gmail.com> wrote:
>>> Sounds good to me.
>>>
>>>
>>>>
>>>>
>>>>
>>>> On Jul 13, 2012, at 1:16 PM, Kalle Korhonen <kalle.o.korhonen@gmail.com>
>>>> 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: 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
>>>>
>>>
>>>
>>> --
>>> Thiago H. de Paula Figueiredo
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
> ---------------------------------------------------------------------
> 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