I have given the id of the input text with date_m. When I try to access the page it gives an error saying component id date_m not found in view. But I do not get this error when the id is changed to date-m. Does JSF not allow underscore for id's? IN our project the javax.faces.SEPARATOR_CHAR is underscore.
<h:inputText id="date_m" value="{bean.month}"/>
<h:message id="error" for="date_m"/>
The component ID should not contain the same character as the separator character. That's among others why the default separator character is :. You cannot use it in the component ID, it would be invalidated according the rules of UIComponent#setId(), but it is allowed in HTML element IDs.
However, if you change the default separator character by a javax.faces.SEPARATOR_CHAR context parameter to a character which is allowed in component IDs, then you should be double as careful when specifying component IDs. You should namely make sure that you don't use exactly the separator character in the component ID, otherwise the UIViewRoot#findComponent() method may break. This method is internally used by JSF to find components by client ID.
So, if your separator character is _, then you should use it nowhere in your component IDs. The logical consequence is to consequently use - instead.
See also:
How to use JSF generated HTML element ID with colon ":" in CSS selectors?
If your separator character is "_" then I think you have confused the lookup algorithm by using an underscore in your id field.
Try removing the underscore (from "date_m" to "datem") and see what happens then.
Related
I use XSLT 1.0 to transform source XML file to HTML document. In source file there are section elements.
<section name="Name of this section">
...
</section>
And it is transformed to HTML as following (h2 may change to h3, h4, etc. according to the level of nesting).
<h2 id="...">Name of this section</h2>
id attribute is used to reference this section from other HTML document.
Link to the section
Currently geterate-id function is used to generate the value of id attribute. But it may change when structure of source XML file is changed. And it results in breakage of link from other HTML document. So I would like to make value of id attribute constant even if structure of source file is changed.
At first I considered using the value of name attribute. But sometimes it includes characters that is improper as a part of URL (space, question mark, non-ASCII UTF-8 characters, etc.). So it can't be used.
Next I considered adding id attribute to section element of source XML file and using it as is in HTML file. It surely provide proper value but adding it to all section element in source file is bothersome. So I would like to think of it as last resort.
Then is there any way to generete the value of id attribute that is constant regardless of change of source file and also proper as a part of URL?
Maintainer of documents referencing mine told me encode-for-uri() of XSLT 2.0 and str:encode-uri() of EXSLT. I use xsltproc of libxslt as processor and it supports EXSLT. So I decided to use str:encode-uri(#name) as value of id attribute. There are two drawbacks about it. At first it doesn't guarantee uniqueness. If there are multiple section elements with the same name attribute value in source XML file, then id value will be duplicated. The second point is that when the value of the name attribute changes, the id value also changes. However, in my case they don't really matter. The value of name attribute is unique within source file and seldom changed. So I can make id unique and almost constant enough for my case.
I working on a routine that parses a URI. Among obvious cases there is an empty string case. Is the empty string a valid input? What would be an outcome URI of an empty string?
An empty string can’t possibly be a URI. The general URI syntax specifies that at least the scheme component followed by a : followed by the hier-part component (which may be empty) must be present.
But a relative URI reference can be empty. The syntax of relative references specifies that at least the relative-part component must be present, but it’s allowed to be empty (path-empty).
An empty relative URI reference is a same-document reference (bold emphasis mine):
The most frequent examples of same-document references are relative references that are empty or include only the number sign ("#") separator followed by a fragment identifier.
Since the root of a URI is a limited set we know it does not have a valid root.
It therefore does not identify anything and is invalid as an identifier. But this might have a meaning in your context still since tere is no specific standard for a URI.
You can parse an empty String to a Uri without an exception but its fields will be null or their default invalid values.
val myUri = Uri.parse("")
myUri.host is null and
myUri.port is -1
I often have Javascript on my JSF XHTML pages that has && in it, which I end up having to encode as &&
For example, when I place the following in my JSF XHTML page file:
I am an & sign
I get the error:
The entity name must immediately follow the '&' in the entity reference
One wayto fix this appears to be to change the '&' to & which I find undesirable to just writing '&'.
It also appears that for cases where I use the '&' in Javascript, I can wrap the Javascript in CDATA tags; when wrapped in CDATA tags, I can then write '&' without having to escape it as &, which is a good workaround to be able to have more readable Javascript code on my page.
But what happens when I want to use the literal '&' elsewhere on the page when it is not within <script> tags and therefore cannot as easily wrap the code in CDATA tags? Must I always escape '&' as & for these cases?
Note trying to use 's ability to escape values and do not seem to be able to fix the issue
Facelets is a XML based view technology. Any characters which have special treatment by the XML parser needs to be XML-escaped when the intent is to present them literally. That covers among others < and &. The < indicates the start of a XML tag like so <foo> and the & indicates the start of a XML entity like so &. The < must be escaped as < and the & as &.
Not escaping them in Facelets would result in the following exception for <
javax.faces.view.facelets.FaceletException: Error Parsing /test.xhtml: Error Traced[line: 42] The content of elements must consist of well-formed character data or markup.
and the following one for &
javax.faces.view.facelets.FaceletException: Error Parsing /test.xhtml: Error Traced[line: 42] The entity name must immediately follow the '&' in the entity reference.
This is not specifically related to JavaScript, this applies to the entire view, including "plain text". Those characters just happen to be JavaScript operators as well. There's no way to go around this, that's just how XML is specified. In JavaScript, there's however one more way to avoid escaping or using CDATA blocks: just put that JS code in its own .js file which you load by <script> or <h:outputScript>.
In EL, there is also the && operator which also needs to be escaped as && as well, but fortunately there's an alias for this operator, the and operator.
See also:
Mozilla Developer Network - Writing JavaScript for XHTML
It's because & is special characters in XML : http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references
FYI, I tried to write the (c) character in my JSF page.
An error was raised when I wrote © : "copy is referenced but not declared"
When I wrote © I got the raw string back.
I could display the special character using the unicode notation : ©
This code worked for me :
<h:outputText value="©" escape="false" />
In my asp.net mvc page I create a link that renders as followed:
http://localhost:3035/Formula/OverView?colorId=349405&paintCode=744&name=BRILLANT%20SILVER&formulaId=570230
According to the W3C validator, this is not correct and it errors after the first ampersand. It complains about the & not being encoded and the entity &p not recognised etc.
AFAIK the & shouldn't be encoded because it is a separator for the key value pair.
For those who care: I send these pars as querystring and not as "/" seperated values because there is no decent way of passing on optional parameters that I know of.
To put all the bits together:
an anchor (<a>) tag's href attribute needs an encoded value
& encodes to &
to encode an '&' when it is part of your parameter's value, use %26
Wouldn't encoding the ampersand into & make it part of my parameter's value?
I need it to seperate the second variable from the first
Indeed, by encoding my href value, I do get rid of the errors. What I'm wondering now however is what to do if for example my colorId would be "123&456", where the ampersand is part of the value.
Since the separator has to be encoded, what to do with encoded ampersands. Do they need to be encoded twice so to speak?
So to get the url:
www.mySite.com/search?query=123&456&page=1
What should my href value be?
Also, I think I'm about the first person in the world to care about this.. go check the www and count the pages that get their query string validated in the W3C validator..
Entities which are part of the attributes should be encoded, generally. Thus you need & instead of just &
It works even if it doesn't validate because most browsers are very, very, very lenient in what to accept.
In addition, if you are outputting XHTML you have to encode every entity everywhere, not just inside the attributes.
All HTML attributes need to use character entities. You only don't need to change & into & within script blocks.
Whatever
Anywhere in an HTML document that you want an & to display directly next to something other than whitespace, you need to use the character entity &. If it is part of an attribute, the & will work as though it was an &. If the document is XHTML, you need to use character entities everywhere, even if you don't have something immediately next to the &. You can also use other character entities as part of attributes to treat them as though they were the actual characters.
If you want to use an ampersand as part of a URL in a way other than as a separator for parameters, you should use %26.
As an example...
Hello
Would send the user to http://localhost/Hello, with name=Bob and text=you & me "forever".
This is a slightly confusing concept to some people, I've found. When you put & in a HTML page, such as in <a href="abc?def=5&ghi=10">, the URL is actually abc?def=5&ghi=10. The HTML parser converts the entity to an ampersand.
Think of exactly the same as how you need to escape quotes in a string:
// though you define your string like this:
myString = "this is \"something\" you know?"
// the string is ACTUALLY: this is "something" you know?
// when you look at the HTML, you see:
<a href="foo?bar=1&baz=2">
// but the url is ACTUALLY: foo?bar=1&bar=2
My website is XHTML Transitional compliant except for one thing: the & (ampersand) in the URL are written as it is, instead of &
That is, all the URLs in my pages are usually like this:
Foo
But XHTML validator generates this error:
cannot generate system identifier for general entity "y"
... and it wants the URL to be written like this:
Foo
The problem is that Internet Explorer and Firefox don't handle the URL correctly and ignore the y parameter. How can I make this link work and validate correctly?
It seems to me that it is impossible to write XHTML pages if the browsers don't work with strict encoded XHTML URLs.
Do you want to see in action? See the difference between these two links (copy and paste them as they are):
http://stackoverflow.com/search?q=ff&sort=newest
and
http://stackoverflow.com/search?q=ff&sort=newest
I have just tried this. What you attempted to do is correct. In HTML if you are writing a link the & characters should be encoded as & You would only encode the & as %26 if you wanted a parameter value to contain an ampersand. I just wrote a simple HTML page that contained a link: Click me
and it worked fine: default2.aspx received the parameters intended and the source passed validation.
The encoding of & as & is required in HTML, not in the link. When the browser sees the & in the HTML source for a link it will interpret it as an ampersand and the link target will be as intended. If you paste a URL into your browser address bar it does not expect it to be HTML and does not try to interpret any HTML encoding that it may contain. This is why your example links that you suggest we should copy/paste into a browser don't work and why we wouldn't expect them to work.
If you post a bit more of your actual code we might be able to see what you have done wrong, but you appear to be heading the right direction by using & in your anchor tags.
It was my fault: the hyperlink control already encoded &, so my URL http://foo?x=1&y=2 was encoded to http://foo?x=1&y=2
Normally the & inside the URL is correctly handled by browsers, as you stated.
You could use & instead of & in your URL within your page.
That should allow it to be validated as strict XHTML...
Foo
Note, if used by an ASP.NET Request.QueryString function, the query string doesn't use XML encoding; it uses URL encoding:
/mypath/mypage?b=%26stuff
So you need to provide a function translating '&' into %26.
Note: in that case, Server.URLEncode(”neetu & geetu”), which would produce neetu+%26+geetu, is not what you want, since you need to translate & into %26, not just '&'. You must add a replace() call applied to URLEncode result, in order to replace '%26amp;' by '%26'.
To be even more thorough: use &, a numeric character reference.
Because & is a character entity reference:
Character entity references are defined in the markup language
definition. This means, for example, that for HTML only a specific
range of characters (defined by the HTML specification) can be
represented as character entity references (and that includes only a
small subset of the Unicode range).
That's coming from the wise people at W3C (read this for more).
Of course, this is not a very big deal, but the suggestion of W3C is that the numeric one will be valid and useable everywhere and always, while the named one is 'fine' for HTML but nothing more.
The problem is worse than you think - try it in Safari. & gets converted to & and the hash ends the URL.
The correct answer is to not output XHTML - there's no reason that justifies spending more time on development and alienating Mac users.