I'm looking to give our users some wiki-style editing capabilities (much like I'm using now) on our Rails web application. Does anyone have any opinions on whether I should use Markdown/BlueCloth or Textile/RedCloth (or something else entirely)?
Also, related to this question, is BlueCloth secure from a XSS perspective?
Thanks.
I find that Markdown tends to be easier for people to learn (since it looks like how people usually "style" plaintext) and less closely tied to the underlying HTML. Textile has tons of ways of specifying headers and HTML classes and so on — useful for a one-man blog, not so much for a general-purpose templating engine.
For Ruby Markdown support, I'd consider RDiscount. But neither Markdown nor Textile does anything to protect you from XSS as far as I know.
I personally prefer Textile, both in syntax and ease of use. I've had quite a few problems even getting Markdown working, but Textile was a snap.
I've been using Textile with custom code, plus this Javascript textarea editor for the client-side editor and it's performed well.
Textile also converts a lot of shorthands to their proper typographical/grammatical equivalents (ie. -- to an em dash) which is nice for publishing or print websites, or again just as a personal preference.
Actually, Textile has a "restricted" mode which should prevent XSS attacks.
Textile Reference Manual
Consider which markup language has good WYSIWYG helpers if you need to provide that functionality. I found these for Textile, but I don't know what's available for Markdown.
Related
There's no scarcity of WYSIWYG editors, but it seems like there's no simple path to having one and keeping some semblance of protection from bypassing client side validation and including script and object tags.
My initial thought was to find a WYSIWYG editor which would output markdown, then store markdown formatted text in the db and parse on display. This would protect me from storing potentially dangerous code in the db, but also keep me from needing to whitelist every possible tag that the editor would put out as I would need to if it were HTML.
Am I missing some really easy path here? How does everyone else balance having a usable editor but not opening themselves wide open to attacks?
Ryan Grove's sanitize gem is very customizable, and I think the basic or relaxed modes would work for sanitizing raw html from the WYSIWYG editor (and you wouldn't have to whitelist a bunch of tags).
I'm potentially looking to standardize view/design templates for projects across the board with a singular template framework. Given that we are starting to see work for JS frameworks that can leverage Handlebars, it would seem potentially prudent to likewise begin using Handlebars to replace our usage of HAML (via Handlebars.rb and handlebars_assets).
Does this, experientially, work effectively? Or can you provide a link to some explanation of why or why not this will work or an example of such a use case?
Obviously HAML and (more sexy) Slim offer a cleaner template syntax for the most part, but Handlebars.js does have advantages that it carries from Liquid in that it's much more like plain HTML and therefore more "designer friendly."
I love HAML, however recently our projects have come under some scrutiny with regards to reliance on non-html structured templates. I thought I'd take it a step further by asking the question, "How can we use pure HTML design based templates in Ruby on Rails?"
The closest thing I've found so far is a very interesting project that has it's most recent update from 2010 called Kwartz from the author of Erubis.
Is there a project that upholds this pure HTML isolation for designers that is up-to-date and viable on Rails 3.2.x?
Your designers are correct that HAML does not have widespread HTML tool support.
A really excellent solution IMHO is Handlebars. It is simpler than HAML, and will work with more HTML tools because Handlebars emphasizes moving code out of the page template and into the controller. This also is good for writing maintainable pages with designers and also for security.
Handlebars is led by Yehuda Katz, who helped write Rails 3, is a core contributor to JavaScript, and is currently working on Ember.js which also leverages Handlebars.
http://handlebarsjs.com/
You are either going to do something with the templates, right? As in, the designer gives you the template, you strip out the parts that already belong to app/views/layouts/application, inject the necessary ruby to get your data into the view etc.
So what's the problem? Let the designers provide their templates in HTML, you convert them to HAML when using in the app, instead of converting them to ERB.
I am currently looking for a markup language to use in a project. I want to allow site vistors to edit a wiki like page using a markup language (not HTML).
I am implementing this site in Ruby on Rails, and would prefer (although not bound) to use something that already has strong support in the form of a gem.
There are a few main things I am looking for in a markup language:
It needs to be easy to use for a
non-technical crowd.
It needs to be safe from cross site
scripting attacks.
It needs to be relatively useful for
general purpose markup found in wiki
pages.
Ideally support would have be there
in the form of a gem.
Ideally a WYSIWYG editor (or at least
an editor with helpers like the one
on SO) would exist.
From a brief survey of the popular markup language I am inclined to go with Markdown, only because it seems to have good support in RoR and (if I am not mistaken) it also appears to be free from cross site scripting exploits.
Are these valid observations? What down falls are there to going with Markdown? What other concerns would you look at when choosing a markup language? And most importantly, which markup language would you choose?
Any and all information would be appreciated.
As a side note, I've already looked at Compare and contrast the lightweight markup languages and it didn't directly address my concerns, but perhaps would be helpful for those looking at this question.----
How about Creole?
That seems to be well suited for wikis, and looks to have Ruby support and since it also has Javascript support, so an editor similar to SO's can be crafted.
See:
Creole-to-HTML converter
JavaScript Creole 1.0 Wiki Markup Parser
This seems old but I've found an answer which is a gem called "redcarpet"
https://github.com/vmg/redcarpet
http://rubygems.org/gems/redcarpet
Personally I'd use an html scrubber such as loofah to sanitize rather than depending on markup, certainly it's useful to allow some html. I personally recommend markdown with wmd wysiwym editor which is what SO use; in fact they're pretty much maintaining it these days. Being able to separate link and image urls to the bottom of the markup is very worthwhile and far user friendlier.
While I have experience developing Rails apps in English, I am a blank slate when it comes to handling globalization, so please don't shoot me in the head if my question 'doesn't make sense' :)
I have been asked to add multi language feature to a part of a Rails app that I am working on. Initially its only going to be 2 languages, French and German. The content that will be translated (which is in English now) is rendered using partials at the moment hence I am getting a bit inclined on creating partials with different languages and then based on the users language selection call the relevant partial - Would you recommend this approach?
Although it seems a heavy weight solution for this particular purpose, but I am also looking at the Rails Globalize plugin. This seems to appeal if I look at the long term gains, something like what if later I am asked to translate the entire app.
Any insights on what would be a proper structured approach to handle globalization in Rails?
Many Thanks
Have you had a look at the i18n (internationalization) API that is in Rails itself as of 2.2? It makes it easy to store your language translation files as .yml files, so a fr.yml and a de.yml or whatever. It also steps through different approaches of making languages accessible via browser prefs, or URLs, subdomains, etc. In your HTML template files you use symbols to specify the keys for the string you've translated. At least in my basic usage and testing, it was very easy to work with.
I preffer using translator instead of Rail's i18n, since the former handles "scoping of translation" automatically. I recommend you give it a look.
This is a great article on how to use Ruby's GetText to localise you Rails App.