[
https://issues.apache.org/jira/browse/CLK-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731169#action_12731169
]
Bob Schellink commented on CLK-564:
-----------------------------------
> With the CssStyle and JsInclude you are already using the TemplateService to
> dynamically render the content. I am not sure what the value add here would
> be.
Not sure I follow. The only reason I mentioned CssStyle and JsInclude templates
is when using eager loading we will end up caching the JsScript and JsInclude
scripts in the ResourceService because these files have *.js or *.css
extensions. So ResourceService will think they are static resources where in
reality they are Velocity templates. When Velocity renders these templates they
are cached by Velocity as well and so we end up caching these resources twice.
If we only cater for /click/* resources there is no worries because we don't
have any *.js or *.css templates. If we try and cater for things such as
/clickclick/* we would have this issue because clickclick uses quite a number
of these templates.
With lazy loading this problem goes away because we will only load resources
that are requested by the browser. Since the templates are not static
resources, the browser won't request them and ResourceService won't cache them.
I'm quite happy with the ResourceService as it stands now and will test it out
in the next couple of days on GAE.
> Add ResourceService for serving static resources
> ------------------------------------------------
>
> Key: CLK-564
> URL: https://issues.apache.org/jira/browse/CLK-564
> Project: Click
> Issue Type: New Feature
> Components: core
> Affects Versions: 2.0.2
> Reporter: Malcolm Edgar
> Assignee: Malcolm Edgar
> Fix For: 2.1.0 RC2
>
>
> The Click static resource deployment strategy of writing *.htm, *.css and
> image files to the web application /click/ directory does not work on all
> application servers. In particular WebLogic and WebSphere have security
> restrictions which prevent this from occuring. In these scenarios users are
> have to deploy these applications to the WAR file at build time. Google GAE
> also does not support this deployment mode.
> A solution to this problem is to use the ClickServlet to serve these
> resources. By adding an additional web.xml mapping:
> <servlet-mapping>
> <servlet-name>ClickServlet</servlet-name>
> <url-pattern>/click/*</url-pattern>
> </servlet-mapping>
> The ClickServlet could use a ResourceService interface obtained from the
> ConfigService which returns the resource data. A default ClickResourceService
> would be provided which loads all the resources at application initialization
> time. This service would scan all the JAR files for resources in META-INF/web
> as is currently done in XmlConfigService and would cache them in memory. The
> service would also scan all the resources under the WAR /click/ directory.
> These resources would override any defined in the application JAR files.
> This could be a good feature for 2.1.0, we should possibly delay the 2.1.0 RC
> release to include this feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
