I figured out most of it.
I had to implement an Asset Factory, an Asset Alias Manager, an Asset Resource
and an Asset Provider annotation (pretty similar to URI Asset Factory in
chenille kit). No bindings were necessary. Instead of injecting an Asset, I
look it up.
asset = assetSource.getAsset(null,
"paramasset:${server_host}${css_root}/commons.css", null);
renderSupport.addStylesheetLink(asset, null);
The asset alias manager looks up the values for the variables ${server_host}
and ${css_root} provides the right asset.
This all works fine, except that I had to do some ugly hacks in my
implementation of Resource.
1) toURL():
I return a fake URL because you cannot create a URL instance of a string
like "paramasset:${server_host}${css_root}/commons.css"
This is not a valid URL string obviously, and variable expansion happens
later on by Asset Alias Manager.
2) forLocale(Locale locale):
#1 made all calls to toURL() return a non-null value, so it broke
localization. So I had to implement forLocale method and have it the
non-localized version.
Thereby giving up localization.
I couldn't extend AbstractResource due to #2. My css files are on a separate
server (on a CDN) and I'd rather not create a HTTP connection just to make sure
they exist (for performance reasons). Is there a cleaner and simply better way
of handling this? Also I'd rather not give up localization.
Thanks so much,
Dave
----- Original Message ----
From: Dave Greggory <davegregg...@yahoo.com>
To: Tapestry users <users@tapestry.apache.org>
Sent: Sunday, February 8, 2009 9:07:18 AM
Subject: Re: Dynamic Variables in Asset declarations
So, tell me whether I have this straight.
In order to create Asset instances based on URL (actual asset CSS files
residing on a completely different web server = CDN) like below:
@Inject
@Path("paramasset:${server_host}${css_root}/commons.css")
private Asset myCommonAsset;
server_host varies from environment to environment (QA/staging/production).
css_root varies from request to request as it depends on request params
(basically different users have different themes).
To do this, I would need to implement a new Asset Factory, an Asset Binding, an
Asset Binding Factory and an Asset Resource. Is that correct?
Do I really need the binding and binding factory? Can I implement the above
functionality without the new "paramasset" domain?
I tried stepping through the Classpath Asset and Context Asset factories and
bindings while debugging, but it was little confusing. Can anyone clarify to me
how all these fit together?
Thanks,
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
