I have a couple of CSS files that I don't want to combine, but I also want to bust cache for those resources, so I declared them with:
<h:outputStylesheet name="css/styles.css?version=#{startup.time}" />
It was working fine until I added the CombineResourceHandler. Now the new handler does not recognize the name of the resource, and I cannot use a wildcard to exclude those resources, something like:
<context-param>
<param-name>org.omnifaces.COMBINED_RESOURCE_HANDLER_EXCLUDED_RESOURCES</param-name>
<param-value>css/styles.css*</param-value>
</context-param>
If I remove the version parameter I have to do versioning of those files, which is something I would like to avoid.
Any ideas on how to implement this the easiest way?
OmniFaces identifies resources by the internal ResourceIdentifier class. It didn't take into account any query strings, path parameters nor path fragments. As per this commit, this has been fixed. The fix is available in today's latest 2.2-SNAPSHOT.
Support for wildcard pattern in excluded (and suppressed) resources context param would be a good candidate for a feature request.
Related
The CMIS 1.1 specification says:
2.1.5.3 Paths
A folder hierarchy MAY be represented in a canonical notation such as path.
[...]
A pathSegment token MUST not include a ’/’ character.
It is repository specific how a repository chooses the value for pathSegment. Repositories might choose to use cmis:name or content stream filename for pathSegment token.
But, I was able to create the document below in a Documentum 7.1.0000.0146 server:
As you can see, both cmis:name and cmis:contentStreamFilename contain a slash. Actually, it seems that cmis:contentStreamFilename becomes whatever cmis:name is (plus the extension).
Is this a bug in Documentum's CMIS implementation?
While this server replies correctly to "normal" getObjectByPath requests with cmis:name path elements, is there any way to use getObjectByPath for the object in the screenshot above? Or is getObjectByPath unusable with such a server?
I do believe it is a bug in Documentum's CMIS implementation (meaning, it's a bug to allow the slash to be part of cmis:name and cmis:contentStreamFileName). I found this bug report from the Apache Chemistry Jira project, where it seems a similar bug was fixed. Some comments that shed some light on the issue:
Given the following path to an object:
/a/b/c/d.pdf
The path segment tokens are "a", "b", "c", and "d.pdf".
The getObjectByPath method does assume that you will pass it a path comprised of path segment tokens separated by forward slashes. This is how CMIS defines a "path" per the spec.
...and...
Repository might use cmis:name for pathSegment token, however, if repository doesn't use cmis:name as pathSegment token, this case will fail obviously.
There're some possible scenarios that cmis:name is not used as pathSegment token:
1) Content stream file name is used rather than cmis:name as it is described in the spec.
2) Repository supports to create document with same cmis:name in a folder, which means it is inevitable to use other value rather than cmis:name as its pathSegment since "The pathSegment token for each item MUST uniquely identify the item in the folder" according to the spec.
I don't know Documentum specifically, so whether this bug would manifest when fetching the object is a coin toss. Have you considered using CMIS Workbench to run a simple CMIS query to find it using one of those properties? If it worked, I'd be pretty confident (though not 100%) it would work with getObjectByPath.
I do not think there are much restrictions on object names in a Documentum repository.
If you want to apply a business rule to ensure no object names are created with the '/' character then have a look at the BOF framework.
In JSF sources I found the logic of defining character encoding via facelets.Encoding attribute, which can be available in FacesContext.getAttributes()
See FaceletViewHandlingStrategy#getResponseEncoding method for details. How can I define this attribute for instance of FacesContext? I tried to define it via context-param in web.xml, but it's not working. And also I didn't find any reference about it in JSF documentation.
The main reason why I want do this, it is overriding of javax.faces.request.charset value. I don't want define a special filter for my application the order to define not UTF-8 encoding. Because my application contains a lot of WAR packages inside of big EAR.
I'm quite stuck on an unexpected problem. I'm trying to use Wayfinder to generate a sitemap for a project. The output of the navigation items is as expected, but I need to include a number of documents in addition to the primary navigation elements.
To do this, I have used the includeDocs parameter.
[[Wayfinder? &startId=`0` &includeDocs=`17,18,19,20`]]
When I do this, I get no output at all. Remove includeDocs and I get the standard nav (expected). Use the param and the output is completely empty.
No idea what I'm doing wrong or what (if any) other setting must be defined in order to make this work.
The includeDocs parameter is very misleading. It should rather be named "onlyIncudeDocs" or "restrictTo", since that is what it does. It also requires the docs you include to be directly accessable from your startId, alternatively have the entire path "included".
I would suggest you create weblink resources directly under your startId, and link them to the resources you want to include. That way wayfinder will pick them up by default. (Note that you may need to handle this in your rowTpl for wayfinder, since a weblink stores the actual link in it's content field)
If you also want to include the children of the id's you specify, you would probably be better of slightly revising your resource structure.
I have some static variables used the XSL which are currently stored in sitemap.xml as global variables.
<map:pipelines>
<map:component-configurations>
<global-variables>
...
</global-variables>
</map:component-configurations>
...
This is all well and good but, some of the variables are deployment specific so need to be changed when the web app starts up. Basically, I need a small number of properties, stored externally to the .WAR to be available in the XSLT.
Has anyone needed to do something similar? If so what approach did you use?
thanks
For reference, it's worth checking out the cocoon input module RequestModule
Why exactly do these properties need to be stored outside of the WAR? Cocoon already keeps plenty of deployment-specific configuration inside WEB-INF.
If you're simply trying to keep the configuration out of the sitemap, .properties files may be your solution. The properties defined in **.properties in WEB-INF are available for use in Cocoon's sitemaps using ${property-name} notation.
Note that my answer is based off my experience with Cocoon 2.1.11; it may work differently in other versions.
Commonly movable type will publish HTML files which contains absolute path, but if I want to host the site under different domain(e.g., both HTTP and HTTPS), it is very inconvenient.
So is there a way to change all the paths to resource of my site to absolute ones?
Thanks
I think you want "reletive" paths. The relative directories can be symlinked/aliased on the server. Once file paths are aliased...
Update your mt-config.cgi file to use reletive paths for the required config directives:
StaticWebPath
CGIPath
This is also covered in the installation guide
Short of constructing the URLs yourself in your templates, you'll need a plugin. I've found that MTRelativeURL works well, despite not being updated in a while.
The plugin adds a few new tags but the simple approach is to use the 'relative_url' filter where needed:
<$MTEntryPermalink relative_url="1"$>
Keep in mind that you'll want to continue using absolute URLs for the links in your RSS feed.