Just for backward compatibility, what about adding a symbol defaulting to
false that allows assets to be loaded from outside /META-INF/assets?
On Sun, 22 Jul 2012 15:43:47 -0300, Howard Lewis Ship <[email protected]>
wrote:
Just a note on where I'm heading with the 5.4 code.
In Tapestry 5.3 and earlier, classpath assets were allowed to be
anywhere on the classpath, as long as the assets where somewhere under
a library root package. Tapestry would build an asset URL that
incorporated the library name and the relative path from that root to
the asset. So, move_up.png in org.apache.tapestry5.corelib.components
would be combined with the library name "core" ->
"org.apache.tapestry5.corelib" to create as asset URL of
/assets/123bc/core/components/move_up.png
Of course, this has its problems including how to handle libraries
that have multiple root packages (Tapestry builds a path relative to
the deepest common folder) and, more importantly, how to keep users
from downloading things that were not intended to be downloaded,
including Java .class files and Tapestry templates and properties
files. You end up with some extra cruft, such as attaching an md5
checksum to certain assets to "prove" that the application intended to
expose it to the client. It still makes people unhappy, as parts of
the /assets/ namespace is browsable (via the web browser); further
protection on files requires opt in (you must declare which extensions
need extra protection). All in all, less than satisfactory.
I believe Thiago pointed out, maybe a year back, that it would have
been better to isolate assets from other things on the classpath. I
agree, and in 5.4 I'm starting a transition that way. The current
approach will continue to be supported until at least 5.5, with
runtime warnings.
The new approach is that assets go in /META-INF/assets/<library name>
(or just /META-INF/assets/ for application classpath assets). Relative
URLs are now relative to that folder, not relative to the component
class. Again, outside of some warnings, all existing assets work
correctly using 5.3 rules.
The warnings I mention above include where to move the file so that it
will be picked up correctly:
[ERROR] AssetSource Packaging of classpath assets has changed in
release 5.4; Assets should no longer be on the main classpath, but
should be moved to 'META-INF/assets/' or a sub-folder. Future releases
of Tapestry may no longer support assets on the main classpath.
[ERROR] AssetSource Classpath asset
'/org/apache/tapestry5/corelib/components/sort-asc.png' should be
moved under folder '/META-INF/assets/core/', and the relative path
adjusted.
[ERROR] AssetSource Classpath asset
'/org/apache/tapestry5/corelib/components/sort-desc.png' should be
moved under folder '/META-INF/assets/core/', and the relative path
adjusted.
[ERROR] AssetSource Classpath asset
'/org/apache/tapestry5/corelib/components/sortable.png' should be
moved under folder '/META-INF/assets/core/', and the relative path
adjusted.
The location of resources (component templates and message catalogs)
is not changed.
One of my secondary goals will be to have a way of generating a kind
of manifest of all assets (classpath or context, static or virtual)
that can be used to pre-load assets into a CDN.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
