I see,
so I guess this environment-info somehow is encoded inside the URL (e.g.
test.company.org resources should go to different server as
company.org). Then maybe it is worth to introduce kind of a environment
service which parses URL and sets environment properties. You could
reuse this approach also (e.g. for different DB-modes and connections).
Generally I would not put such an environment setup thing to the
asset-declaration but encapsulate it somewhere else
(EnvironmentModeService + injecting this to AssetFactory).
Dave Greggory schrieb:
Unless I misunderstand things completely, I don't think this is possible.
Because the values for those variables are determined from request
params/attributes.
----- Original Message ----
From: manuel aldana <ald...@gmx.de>
To: Tapestry users <users@tapestry.apache.org>
Sent: Sunday, February 8, 2009 7:45:32 PM
Subject: Re: Dynamic Variables in Asset declarations
Instead of passing ${server_host}${css_root} to the asset annotations you could
use plain old properties which are then loaded to the environment and passed to
the AssetFactory.
@Inject
@Path("cdn:path/aboveRoot")
private Asset asset;
Dave Greggory schrieb:
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
-- manuel aldana
ald...@gmx.de
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
manuel aldana
ald...@gmx.de
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
