You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Dave Greggory <da...@yahoo.com> on 2009/01/29 20:34:18 UTC
Dynamic Variables in Asset declarations
Hello,
I'm trying to declare an asset but with a dynamic variable used for declaration. I need a dynamic variable (similar to an expansion in a tml) because the css is selected based on some user selected parameters from the request.
E.g.
@Inject
@Path("${myCssRoot}/style.css")
private Asset style; public String getMyCssRoot()
{
String value = (some logic to determine value of string based on request params/url)
return value;
}
I have about 5 stylesheets each having about 10 different variations. I don't want to manually declare all 10 variations and have 50 asset declarations in a component or page.
Since expansions in the @Path annotation are symbols, would I be able to handle this by contributing a custom Symbol Provider? Documentation isn't very clear about the method signature to use in AppModule to contribute a symbol provider.
But it seems to me that the existing symbol providers work with configuration available at application deploy time, not run time information like request params or urls. Is it possible to build a Symbol Provider that can be injected with a Request and use that?
Or is there a different way to handle this?
Thanks,
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Variables in Asset declarations
Posted by Dave Greggory <da...@yahoo.com>.
Hey Jonathan,
Appreciate your idea, but they on a CDN server because we don't want to serve static content from the web application and a CDN (http://en.wikipedia.org/wiki/Content_Delivery_Network) is much better performing at delivering static media.
Dave
----- Original Message ----
From: Jonathan O'Connor <ni...@eircom.net>
To: Tapestry users <us...@tapestry.apache.org>
Sent: Monday, February 9, 2009 5:42:32 AM
Subject: Re: Dynamic Variables in Asset declarations
Dave,
thinking out of the box, can you instead set up some server cron job to
copy the css files over from the other web server to your server. Would
that make it easier?
Jonathan
On 08/02/2009 14:07, Dave Greggory wrote:
> 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
>
>
>
> ----- Original Message ----
> From: Dave Greggory<da...@yahoo.com>
> To: Tapestry users<us...@tapestry.apache.org>
> Sent: Wednesday, February 4, 2009 12:27:37 PM
> Subject: Re: Dynamic Variables in Asset declarations
>
> That could be an option but I thought the beauty of using RenderSupport is that whenever a sub-component add a style sheet to it, it will always go in the<head> section of the page. So each component would have the facility to provide its own stylesheets that will be picked up by the containing page and included in the page's<head> section.
>
>
>
> ----- Original Message ----
> From: Thiago H. de Paula Figueiredo<th...@gmail.com>
> To: Tapestry users<us...@tapestry.apache.org>
> Sent: Wednesday, February 4, 2009 12:58:03 PM
> Subject: Re: Dynamic Variables in Asset declarations
>
> Em Wed, 04 Feb 2009 13:54:51 -0300, Dave Greggory<da...@yahoo.com> escreveu:
>
>
>> Your example may work, but it's not what I'm looking for because the<link> tag is hard coded in the TML.
>>
>
> Couldn't you generate the link tags in code instead of template? I guess you should consider the option of creating a templateless component to generate or not the link tags.
>
> --Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Variables in Asset declarations
Posted by Jonathan O'Connor <ni...@eircom.net>.
Dave,
thinking out of the box, can you instead set up some server cron job to
copy the css files over from the other web server to your server. Would
that make it easier?
Jonathan
On 08/02/2009 14:07, Dave Greggory wrote:
> 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
>
>
>
> ----- Original Message ----
> From: Dave Greggory<da...@yahoo.com>
> To: Tapestry users<us...@tapestry.apache.org>
> Sent: Wednesday, February 4, 2009 12:27:37 PM
> Subject: Re: Dynamic Variables in Asset declarations
>
> That could be an option but I thought the beauty of using RenderSupport is that whenever a sub-component add a style sheet to it, it will always go in the<head> section of the page. So each component would have the facility to provide its own stylesheets that will be picked up by the containing page and included in the page's<head> section.
>
>
>
> ----- Original Message ----
> From: Thiago H. de Paula Figueiredo<th...@gmail.com>
> To: Tapestry users<us...@tapestry.apache.org>
> Sent: Wednesday, February 4, 2009 12:58:03 PM
> Subject: Re: Dynamic Variables in Asset declarations
>
> Em Wed, 04 Feb 2009 13:54:51 -0300, Dave Greggory<da...@yahoo.com> escreveu:
>
>
>> Your example may work, but it's not what I'm looking for because the<link> tag is hard coded in the TML.
>>
>
> Couldn't you generate the link tags in code instead of template? I guess you should consider the option of creating a templateless component to generate or not the link tags.
>
> --Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Variables in Asset declarations
Posted by Dave Greggory <da...@yahoo.com>.
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 <al...@gmx.de>
To: Tapestry users <us...@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 <al...@gmx.de>
> To: Tapestry users <us...@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 <da...@yahoo.com>
>> To: Tapestry users <us...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> -- manuel aldana
> aldana@gmx.de
> software-engineering blog: http://www.aldana-online.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
--
manuel aldana
aldana@gmx.de
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Variables in Asset declarations
Posted by manuel aldana <al...@gmx.de>.
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 <al...@gmx.de>
> To: Tapestry users <us...@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 <da...@yahoo.com>
>> To: Tapestry users <us...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> -- manuel aldana
> aldana@gmx.de
> software-engineering blog: http://www.aldana-online.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
--
manuel aldana
aldana@gmx.de
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Variables in Asset declarations
Posted by Dave Greggory <da...@yahoo.com>.
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 <al...@gmx.de>
To: Tapestry users <us...@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 <da...@yahoo.com>
> To: Tapestry users <us...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
-- manuel aldana
aldana@gmx.de
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Variables in Asset declarations
Posted by manuel aldana <al...@gmx.de>.
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 <da...@yahoo.com>
> To: Tapestry users <us...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
--
manuel aldana
aldana@gmx.de
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Variables in Asset declarations
Posted by Dave Greggory <da...@yahoo.com>.
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 <da...@yahoo.com>
To: Tapestry users <us...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Variables in Asset declarations
Posted by Dave Greggory <da...@yahoo.com>.
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
----- Original Message ----
From: Dave Greggory <da...@yahoo.com>
To: Tapestry users <us...@tapestry.apache.org>
Sent: Wednesday, February 4, 2009 12:27:37 PM
Subject: Re: Dynamic Variables in Asset declarations
That could be an option but I thought the beauty of using RenderSupport is that whenever a sub-component add a style sheet to it, it will always go in the <head> section of the page. So each component would have the facility to provide its own stylesheets that will be picked up by the containing page and included in the page's <head> section.
----- Original Message ----
From: Thiago H. de Paula Figueiredo <th...@gmail.com>
To: Tapestry users <us...@tapestry.apache.org>
Sent: Wednesday, February 4, 2009 12:58:03 PM
Subject: Re: Dynamic Variables in Asset declarations
Em Wed, 04 Feb 2009 13:54:51 -0300, Dave Greggory <da...@yahoo.com> escreveu:
> Your example may work, but it's not what I'm looking for because the <link> tag is hard coded in the TML.
Couldn't you generate the link tags in code instead of template? I guess you should consider the option of creating a templateless component to generate or not the link tags.
--Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Variables in Asset declarations
Posted by Dave Greggory <da...@yahoo.com>.
That could be an option but I thought the beauty of using RenderSupport is that whenever a sub-component add a style sheet to it, it will always go in the <head> section of the page. So each component would have the facility to provide its own stylesheets that will be picked up by the containing page and included in the page's <head> section.
----- Original Message ----
From: Thiago H. de Paula Figueiredo <th...@gmail.com>
To: Tapestry users <us...@tapestry.apache.org>
Sent: Wednesday, February 4, 2009 12:58:03 PM
Subject: Re: Dynamic Variables in Asset declarations
Em Wed, 04 Feb 2009 13:54:51 -0300, Dave Greggory <da...@yahoo.com> escreveu:
> Your example may work, but it's not what I'm looking for because the <link> tag is hard coded in the TML.
Couldn't you generate the link tags in code instead of template? I guess you should consider the option of creating a templateless component to generate or not the link tags.
--Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Variables in Asset declarations
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 04 Feb 2009 13:54:51 -0300, Dave Greggory <da...@yahoo.com>
escreveu:
> Your example may work, but it's not what I'm looking for because the
> <link> tag is hard coded in the TML.
Couldn't you generate the link tags in code instead of template? I guess
you should consider the option of creating a templateless component to
generate or not the link tags.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Variables in Asset declarations
Posted by Dave Greggory <da...@yahoo.com>.
Your example may work, but it's not what I'm looking for because the <link> tag is hard coded in the TML.
I want to decide dynamically whether to add the <link> tags (using RenderSupport). And if so css files selected based on request params and added as <link> tags. These css files are located outside of my server on a CDN (akamai).
As for URIAssetFactory in chenille kit, I have not been able to find an example of its usage. Can any one provide a brief example of where to include the URI Asset Factory and how to use it in the asset declaration? Is it contributed in AppModule, etc?
----- Original Message ----
From: Geoff Callender <ge...@gmail.com>
To: Tapestry users <us...@tapestry.apache.org>
Sent: Wednesday, February 4, 2009 9:48:06 AM
Subject: Re: Dynamic Variables in Asset declarations
Assuming you know how to generate the path to each of your 50 assets,
can you do the following (untested)?
public String getStylesheetPath() {
... figure out the path (relative to the web context, eg. css/
skin01.css), and then return this...
return "asset:context:" + path;
}
and in the html:
<link rel="stylesheet" type="text/css" href="${stylesheetPath}"/>
Ideally I'd have tested this before posting it , but no chance today...
Cheers,
geoff
On 31/01/2009, at 2:36 AM, Dave Greggory wrote:
> Yep, I'm trying to have a dynamic URL for my CSS (not dynamic
> content). I'll checkout chenillekit, thanks for the suggestion.
>
>
>
> ----- Original Message ----
> From: Sven Homburg <ho...@googlemail.com>
> To: Tapestry users <us...@tapestry.apache.org>
> Sent: Friday, January 30, 2009 7:00:22 AM
> Subject: Re: Dynamic Variables in Asset declarations
>
> The URIAssetFactory is located in the chenillekit-core module
>
> 2009/1/30 Massimo Lusetti <ml...@gmail.com>
>
>> On Fri, Jan 30, 2009 at 12:19 PM, Thiago H. de Paula Figueiredo
>> <th...@gmail.com> wrote:
>>
>>> I think Dave is trying to have an asset URL defined dinamically, not
>>> its content . . . For dynamic content, I would use StreamResponse
>>> too.
>>> ;)
>>
>> Look in the chenillkit project, there's an implementation of
>> AssetFactory based on an URL or maybe URI, it could give you ideas.
>>
>> --
>> Massimo
>> http://meridio.blogspot.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> with regards
> Sven Homburg
> http://www.chenillekit.org
> http://tapestry5-components.googlecode.com
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Variables in Asset declarations
Posted by Geoff Callender <ge...@gmail.com>.
Assuming you know how to generate the path to each of your 50 assets,
can you do the following (untested)?
public String getStylesheetPath() {
... figure out the path (relative to the web context, eg. css/
skin01.css), and then return this...
return "asset:context:" + path;
}
and in the html:
<link rel="stylesheet" type="text/css" href="${stylesheetPath}"/>
Ideally I'd have tested this before posting it , but no chance today...
Cheers,
geoff
On 31/01/2009, at 2:36 AM, Dave Greggory wrote:
> Yep, I'm trying to have a dynamic URL for my CSS (not dynamic
> content). I'll checkout chenillekit, thanks for the suggestion.
>
>
>
> ----- Original Message ----
> From: Sven Homburg <ho...@googlemail.com>
> To: Tapestry users <us...@tapestry.apache.org>
> Sent: Friday, January 30, 2009 7:00:22 AM
> Subject: Re: Dynamic Variables in Asset declarations
>
> The URIAssetFactory is located in the chenillekit-core module
>
> 2009/1/30 Massimo Lusetti <ml...@gmail.com>
>
>> On Fri, Jan 30, 2009 at 12:19 PM, Thiago H. de Paula Figueiredo
>> <th...@gmail.com> wrote:
>>
>>> I think Dave is trying to have an asset URL defined dinamically, not
>>> its content . . . For dynamic content, I would use StreamResponse
>>> too.
>>> ;)
>>
>> Look in the chenillkit project, there's an implementation of
>> AssetFactory based on an URL or maybe URI, it could give you ideas.
>>
>> --
>> Massimo
>> http://meridio.blogspot.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> with regards
> Sven Homburg
> http://www.chenillekit.org
> http://tapestry5-components.googlecode.com
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Re: Dynamic Variables in Asset declarations
Posted by Dave Greggory <da...@yahoo.com>.
Yep, I'm trying to have a dynamic URL for my CSS (not dynamic content). I'll checkout chenillekit, thanks for the suggestion.
----- Original Message ----
From: Sven Homburg <ho...@googlemail.com>
To: Tapestry users <us...@tapestry.apache.org>
Sent: Friday, January 30, 2009 7:00:22 AM
Subject: Re: Dynamic Variables in Asset declarations
The URIAssetFactory is located in the chenillekit-core module
2009/1/30 Massimo Lusetti <ml...@gmail.com>
> On Fri, Jan 30, 2009 at 12:19 PM, Thiago H. de Paula Figueiredo
> <th...@gmail.com> wrote:
>
> > I think Dave is trying to have an asset URL defined dinamically, not
> > its content . . . For dynamic content, I would use StreamResponse too.
> > ;)
>
> Look in the chenillkit project, there's an implementation of
> AssetFactory based on an URL or maybe URI, it could give you ideas.
>
> --
> Massimo
> http://meridio.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
with regards
Sven Homburg
http://www.chenillekit.org
http://tapestry5-components.googlecode.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Variables in Asset declarations
Posted by Sven Homburg <ho...@googlemail.com>.
The URIAssetFactory is located in the chenillekit-core module
2009/1/30 Massimo Lusetti <ml...@gmail.com>
> On Fri, Jan 30, 2009 at 12:19 PM, Thiago H. de Paula Figueiredo
> <th...@gmail.com> wrote:
>
> > I think Dave is trying to have an asset URL defined dinamically, not
> > its content . . . For dynamic content, I would use StreamResponse too.
> > ;)
>
> Look in the chenillkit project, there's an implementation of
> AssetFactory based on an URL or maybe URI, it could give you ideas.
>
> --
> Massimo
> http://meridio.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
with regards
Sven Homburg
http://www.chenillekit.org
http://tapestry5-components.googlecode.com
Re: Dynamic Variables in Asset declarations
Posted by Massimo Lusetti <ml...@gmail.com>.
On Fri, Jan 30, 2009 at 12:19 PM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> I think Dave is trying to have an asset URL defined dinamically, not
> its content . . . For dynamic content, I would use StreamResponse too.
> ;)
Look in the chenillkit project, there's an implementation of
AssetFactory based on an URL or maybe URI, it could give you ideas.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Variables in Asset declarations
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, Jan 30, 2009 at 9:10 AM, Massimo Lusetti <ml...@gmail.com> wrote:
> On Fri, Jan 30, 2009 at 12:02 PM, Thiago H. de Paula Figueiredo
> <th...@gmail.com> wrote:
>
>> Couldn't this be easily implemented just using AssetFactory?
>
> I'm not so sure about the easily part of the implementation, I've
> found more easier to implement using the StreamResponse approach as
> I've envisioned the whole Asset part of T5 to be engineered around the
> concept of static resources.
I think Dave is trying to have an asset URL defined dinamically, not
its content . . . For dynamic content, I would use StreamResponse too.
;)
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Variables in Asset declarations
Posted by Massimo Lusetti <ml...@gmail.com>.
On Fri, Jan 30, 2009 at 12:02 PM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> Couldn't this be easily implemented just using AssetFactory?
I'm not so sure about the easily part of the implementation, I've
found more easier to implement using the StreamResponse approach as
I've envisioned the whole Asset part of T5 to be engineered around the
concept of static resources. But probably it could be implemented that
way i simply didn't tried it myself but I'm interested in seeing
anything about.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Variables in Asset declarations
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Couldn't this be easily implemented just using AssetFactory?
On Fri, Jan 30, 2009 at 6:39 AM, Massimo Lusetti <ml...@gmail.com> wrote:
> On Thu, Jan 29, 2009 at 8:34 PM, Dave Greggory <da...@yahoo.com> wrote:
>
>> Hello,
>>
>> I'm trying to declare an asset but with a dynamic variable used for declaration. I need a dynamic variable (similar to an expansion in a tml) because the css is selected based on some user selected parameters from the request.
> [..]
>> Or is there a different way to handle this?
>
> AFAIK this is "missing" from T5, you have to use some mix of
> expansions, Link and StreamResponse to achieve this.
>
> --
> Massimo
> http://meridio.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Variables in Asset declarations
Posted by Massimo Lusetti <ml...@gmail.com>.
On Thu, Jan 29, 2009 at 8:34 PM, Dave Greggory <da...@yahoo.com> wrote:
> Hello,
>
> I'm trying to declare an asset but with a dynamic variable used for declaration. I need a dynamic variable (similar to an expansion in a tml) because the css is selected based on some user selected parameters from the request.
[..]
> Or is there a different way to handle this?
AFAIK this is "missing" from T5, you have to use some mix of
expansions, Link and StreamResponse to achieve this.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org