Here is my problem: I add a message to ModelError with addModelError(String.Empty,”My message”).
In my view I just call #Html.ValidationSummary().
The message is in German and the characters Ö, Ä, Ü are just shown as questionmark. How do I change that?
As I see it there are two options. One option is to write a custom validation summary helper which doesn't HTML encode the messages like described in the link that Kartikeya Khosla provided. Or, and that’s what I did, Just use the Unicode reference in the message string. The solution in Kartikeya is more elegant, but in my case it is a lot of code to change two characters. By the way here a link to look them up if anybody wants to do the same:
http://www.utf8-chartable.de/unicode-utf8-table.pl?utf8=oct&unicodeinhtml=dec&htmlent=1
Related
This should probably be easier than it is. I just want to put a link inside an HTML paragraph element.
%p{class: "answer"}="Please upload your data to this portal in text (tab-separated) format. Download our template #{raw(link_to 'here', '/templates/upload_template.xlsx')} for sample data and a description of each column."
Rails is encoding the tag information. I don't want tags to be encoded. I want them to be tags.
You can use more than one line inside any block, to solve your problem we will have something like this:
%p{class: "answer"}
Please upload your data to this portal in text (tab-separated) format. Download our template
= link_to 'here', '/templates/upload_template.xlsx'
for sample data and a description of each column."
You can use interpolation directly in Haml, and doing this seems to fix the issue in this case.
So instead of doing this:
%p= "Text with #{something_interpolated} in it."
you can just do
%p Text with #{something_interpolated} in it.
i.e. you don’t need the = or the quotes, since you are just adding a single string. You shouldn’t need to use raw either.
(Also, note you can do %p.answer to set the class attribute, which may be cleaner if the value isn’t being set dynamically.)
Why this is being escaped here is a different matter. I would have expected the two cases (%p= "#{foo}" and %p #{foo}) to behave the same way. However, after a bit of research, this behaviour seems to match how Rails behaves with Erb.
Is there any chance to replace the mandrill's *| |* symbols?
The CMS i'm using (MODX) has its own symbols to enclose the tags, eg: [[+ ]]
The case is that I also have "read on web" link, where the page on the web needs to generate dynamic content as well.
I have googled and searched on http://help.mandrill.com but still no luck.
Any hint will be appreciated.
You wouldn't be able to use different symbols in your emails - those are how Mandrill's system recognizes merge tags and to replace them in the HTML and/or text of your email. You'd need to convert any placeholders you have or want for the email to that format, so you can pass the data to Mandrill as expected. If it's going to mirror what you're putting on the web, then you probably just want to have something that transforms strings, for example, to convert your CMS tags to Mandrill tags specifically for the emails.
#kaitlin-mandrill,
Exactly,
I just figured it out.
I need to replace it right before it is sent.
More or less, this is the code.
Hopefully it's useful for anyone else.
I am getting text from a feed that has alot of characters like:
Insignia™ 2.0 Stereo Computer Speaker System (2-Piece) - Black
4th-Generation Apple® iPod® touch
Is there an easy way to get rid of these, or do I have to anticipate which characters I want to delete and use the delete method to remove them? Also, when I try to remove
&
with
str.delete("&")
It leaves behind "amp;" Is there a better way to delete this type of character? Do I need to re-encode the text?
String#delete is certainly not what you want, as it works on characters, not the string as a whole.
Try
str.gsub /&/, ""
You may also want to try replacing the & with a literal ampersand, such as:
str.gsub /&/, "&"
If this is closer to what you really want, you may get the best results unescaping the HTML string. If so try this:
CGI::unescapeHTML(str)
Details of the unescapeHTML method are here.
If you are getting data from a 'feed', aka RSS XML, then you should be using an XML parser like Nokogiri to process the XML. This will automatically unescape HTML entities and allow you to get the proper string representation directly.
For removing try to use gsub method, something like this:
text = "foo&bar"
text.gsub /\b&\b/, "" #=> foobar
In Umbraco CMS, I would like to prevent the contents to have names having invalid URL character such %, > and etc.
How should I do that?
Regards,
Nami
Have a look at your /config/umbracoSettings.config file, it already has a set of replace characters, among which the % character. You can add more if you want to.
If, for any reason you would want to completely prevent those characters in the nodename, you would have to write an afterSave eventhandler so you can do the replace in your own custom code.
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.