That's exactly what I'm doing now. Asset Factory uses the Asset Alias Manager
to parse the request params out.
The problem is in my implementation of Resource.
----- Original Message ----
From: manuel aldana <ald...@gmx.de>
To: Tapestry users <users@tapestry.apache.org>
Sent: Sunday, February 8, 2009 8:13:58 PM
Subject: Re: Dynamic Variables in Asset declarations
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
