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 <ninki...@eircom.net>
To: Tapestry users <users@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<davegregg...@yahoo.com>
> To: Tapestry users<users@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<thiag...@gmail.com>
> To: Tapestry users<users@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<davegregg...@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-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
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
