The rule "title" should be present in all pages is present on the Web Profile of SonarQube. I understand the reason why it exists but I am facing a situation where nothing can be done - so far - to avoid its violation. Let me explain...
When developing using primefaces if the header in xhtml is declared as just "head" tag it does not include some artificats that belongs to the primefaces framework. So, a xhtml like is required
<h:head>
<title>something</title>
....
<h:/head>
But this violates the rule I mentioned in bold.
Maybe because it checks html and xhtml files... not sure.
My thought about that was:
to edit this rule so it would recognize as a complaint code a h:head, or;
change the extension files this rule scans, or;
as last case disable it;
Any ideas about what to do and how to do it?
Related
I have a javascript file under the following folder in my JAR component:
/src/main/resources/META-INF/resources/default/javascript/jquery.marquee.js
If I create a custom JSF component with the following #ResourceDependency annotation:
#ResourceDependency(library = "default", name = "javascript/jquery.marquee.js", target = "head")
The javascript file cannot be found, and in the browser I can see two weird URLs with undefined.css and undefined.js as part of the URL, and also referring the PrimeFaces library ??
http://localhost:8080/acio/javax.faces.resource/undefined/undefined.css.xhtml?ln=primefaces&v=5.3
http://localhost:8080/acio/javax.faces.resource/undefined/undefined.js.xhtml?ln=primefaces&v=5.3
However, if I manually include the script in a XHTML template as follows:
<h:outputScript library="default" name="javascript/jquery.marquee.js" />
Then everything works like a charm as expected, with the expected URL as follows:
http://localhost:8080/acio/javax.faces.resource/javascript/jquery.marquee.js.xhtml?ln=default
I'm completely puzzled about this.
Why, if I use the #ResourceDependency annotation, I get TWO wrong URL's, one about a CSS and another about the JS, related to the PrimeFaces resources, when I'm positively sure the placement of my own JS file is correct? (otherwise the h:outputScript would not work as well)
Tested with Mojarra 2.2.13.SP1 shipped with WildFly 10.1.0.Final, and Mojarra 2.2.12 shipped with WildFly 9.0.2.Final
Any help would be greatly appreaciated !
[UPDATE]
It looks like the the issue may be related to the way we handle page navigation. We are using a SPA approach, with a Facelet template that has a big panel group area inside, with a dynamic JSF include directive. Pages are XHTML fragments that are dynamically included in the template's panel group after an AJAX execution.
It appears that #ResourceDependency only renders the corresponding HTML resource link when a View is created the very first time. As we are using SPA, our View never changes, from the JSF point of view. We handle all the page navigation with AJAX fragment updates using the include directive.
As a test, I placed the tag of my component in the Facelet template itself, instead of a XHTML fragment... and the link is rendered as expected !
It would be great if someone can confirm this behaviour... and if there's any elegant solution to it.
So far, we have to manually include the needed HTML resources on the template definition.
It turns out that the problem goes away when upgrading to PrimeFaces 6.1. Probably Kukeltje is right, and the PF 5.3 Resource Renderer has some kind of bug.
In short, when developing your own JSF PrimeFaces components, PF 5.3 will not render the #ResourceDependency annotations of the JSF component in some situations, like the one described here: using an SPA approach with XHTML fragments.
Moving to PF 6.1 solves the problem. If upgrading is not possible, we have to manually include the needed JS / CSS resources in the fragment with outputScript tags.
Plone 4.1.7
plone.app.theming 1.0
I found this question which is similar to my question except this person wants to do the opposite: remove spaces and carriage returns from Plone content with Diazo(minimizing html code)
I want Diazo to stop stripping out whitespace, as it's stripping out a lot of it that is needed for formatting. This seems to be the case even if my rules.xml is empty - just enabling a theme seems to do it, rather than it being an aspect of a particular theme.
Turning the theme on/off also causes a bug on only one particular page (a view named '##upload') where all of the classes in the <body> tag are stripped out. Unsure if that is at all related, although I do know it's Diazo causing it.
Edit: Some further info: I don't have the non-themed side blocked by host name in the control panel, but rather by use of the <notheme> tag in rules.xml. I have to do this because the non-themed side is on the same domain as the themed side.
I have added the Facebook comments plugin to dynamic pages on my site, and I am attempting to set up administration of those plugins by adding the associated meta tags to their pages. My site uses the CMS dotnetnuke.
I went to the page's settings - under advanced - and added the appropriate meta tag information. However, upon saving, administration is not enabled on that page.
I ran the page through the wc3 validator, and the following error related to that meta tag was produced:
Error Line 11, Column 1926: there is no attribute "property"
…type="text/javascript"></script><meta property="fb:admins" content="76804243"/>
✉
You have used the attribute named above in your document, but the
document type you are using does not support that attribute for this
element. This error is often caused by incorrect use of the "Strict"
document type with a document that uses frames (e.g. you must use the
"Transitional" document type to get the "target" attribute), or by
using vendor proprietary extensions such as "marginheight" (this is
usually fixed by using CSS to achieve the desired effect instead).
This error may also result if the element itself is not supported in
the document type you are using, as an undefined element will have no
supported attributes; in this case, see the element-undefined error
message for further information.
How to fix: check the spelling and case of the element and attribute,
(Remember XHTML is all lower-case) and/or check that they are both
allowed in the chosen document type, and/or use CSS instead of this
attribute. If you received this error when using the element
to incorporate flash media in a Web page, see the FAQ item on valid
flash.
Do I need to specify this attribute somehow in my DNN skin? Any ideas on a possible fix?
Thanks!
Alex
There are several ways you can change the DocType for your site. Here's the entry from the DotNetNuke wiki that describes the options:
http://www.dotnetnuke.com/Resources/Wiki/Page/Set-the-doctype-of-your-skin.aspx
I was using XHTML on my website but that completely destroyed jQuery and its plugins.
Therefore, I want to go back to html 4. I am defining some custom attributes for my html, like so:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd" [
<!ATTLIST mytag myattribute CDATA #IMPLIED>
]>
This seems to be valid html for, but when I pass such a page from my server with a content type of text/html, my browser displays ']>' - it can't parse the doctype properly.
Is there a different content type I should be using?
From A List Apart
If you run such a file through the W3C validator, you find that it
validates wonderfully well. If you download the sample files for this
article and validate file internal.html, you can see this for
yourself. Unfortunately, when you display the file in a browser, the
]> shows up on the screen. There’s no way around this bug, so this
approach is right out.
So this basically isnt going to work. To get it to work you need to copy the DTD you want the server/local machine, edit it appropriately and put it in a publically accessible place. See the article for more detail.
As far as jQuery is concerned, it should work fine if you quit trying to customize the DTD in the fashion that you are. Im not sure about using a custom DTD as I have never done it, but just adding the attributes to the elements and not defining them in the DTD shouldnt cause a problem with jq. Granted the document wont validate, but validation is just a tool and not overly important in the grand scheme of things.
I generate an XHTML document and set the Mime type as "application/msword" so it opens in Word.
To create a header I appear to have to reference an external file thus:
<style>
...
#page{mso-footnote-separator:url("**OUT_files/header.htm**") fs;
mso-footnote-continuation-separator:url("OUT_files/header.htm") fcs;
mso-endnote-separator:url("OUT_files/header.htm") es;
mso-endnote-continuation-separator:url("OUT_files/header.htm") ecs;}
#page Section1{
mso-header-margin:.5in;
mso-header:url("OUT_files/header.htm") h1;
} }
...
</style>
Does anyone know how to reference a div defined within the main XHTML document itself, without having to reference an external file?
Thanks
MS Word is quite locked down. I was not able to get this to work with a non-external file, but it seems to make sense. The values being "included" are repeated in the display. It's not possible to have "hidden" divs and refer to them (at least, not when I was trying), so not sure how to get this to work properly.
For me, I ended up just creating a simple Macro that would handle this for me.
If you are very lucky, a data: URL might work, maybe, in Word 2007? I haven't tried that myself, but MS introduced partial support for data: URLs in IE8.