I am creating a service in which I want to allow end-users to edit HTML templates for web pages that allows for access to specific "variables" for inclusion in the template.
I know that liquid was designed for this very purpose, is secure (at least relatively), and is in heavy production use. However, I find the language to be fairly complex for end-users as compared to something like Mustache.
Mustache sounds great, but I am concerned about security... has it ever been used for end-user templates?
Basically I am looking for a templating engine I can use w/ Rails for end-users that is:
Secure - will not allow the execution of code by the user... at least not on the server. Users will be allowed to insert client-side javascript.
Powerful - allows end-users to create pretty much any web page they can imagine using the supplied "variables" and within the context of #1
Simple - the syntax is clear and easy for end-users to apply
Bonus points if there is support for rendering the template syntax in javascript and other languages.
Liquid meets 1 & 2, but not 3-4. Mustache meets 2-4, but I'm not sure about #1 and that is non-negotiable.
Greatly appreciate any insights, experiences, or comments.
Mustache is fantastic for interpolation and I can't imagine it ever exposing you to server-side vulnerabilities if you're using it for Javascript evaluation. It's the simplest, most powerful option. I don't know that non-programmers would understand it, but I'm sure it's simpler than Liquid.
Another option would be to use an existing simpler user markup set like BBcode or a rich-text editing library like TinyMCE. These are much reduced in functionality, but are easier to use for average people.
Related
I work on a big Active Directory Project where I need to remake the whole intranet application using ASP.NET MVC. I was wandering if Razor was a necessity here ? Especially for forms, I'm having a hard time with Razor forms (what a noob).
I have read that Razor is essential for scalable applications, which I guess is the case here, but if I could dodge this ugly stuff, that would be great.
In the end, do I need to use it for everything?
I have seen examples on the net that use classic HTML forms, and Razor for conditions and such. I don't mind using it for conditions, I just can't figure out how to render my forms with it. Is it ok to use normal html forms, or will it create some scalability issues in the future when I have 1 billion documents? :)
Thanks for your help, hope this isn't too redundant, I've seen this subject all over the place.
You don't need to use the Razor Html Helpers to generate form/input tags (you can use standard HTML markup), but you'll miss out on some of the benefits (specifically integration with a viewmodel to pre-populate fields, validation, etc). You'll also need to make sure your input names match up properly when capturing the FORM POST on the submission side.
It's up to you want you want to go with.
This can help you decide.View Engine Comparison
Instead of using server side MVC like Ruby, Python, PHP to build very complex websites, why should not we split our website into multiple modules, and build each with client side MVC like backboneJS, EmberJS. In this case, we will use PHP / Ruby for creating webservices alone, which will serve data only.
Each module now act as small web app. If we link each other, they will perfectly look like a complex web app.
I visit many websites (like github, groupon, stackoverflow etc...) and they can be built or adopted to this approach. But i am not seeing this kind of approach. Does this approach has any problem on this kind of websites?
Was to long for a comment
I guess the tricky part is indeed the point you mentioned
f we link each other, they will perfectly look like a complex web app.
Because each MVC framework uses a different approach to tackle usual problems you have in modern web-apps, like routing, data binding, application state and rendering DOM elements, so I think you would end up having multiple frameworks doing tasks that overlap substantially, thus forcing you to deactivate or disable some of the built-in functionality of one or the other framework making your frankenstein-app :) very difficult to maintain.
A good example is jQuery-mobile & ember.js, both have a routing system, jQuery uses the DOM to hold state ember.js holds it's state completely in javascript which is much faster. I had a similar problem with a project using jQuery-mobile & ember.js and this forced me to decide for one of the routing systems, I took ember's and deactivated jQuery's wich then let with just a bunch of custom mobile-looking components on the side of jQuery-mobile. Finally I removed jQuery-mobile using ember.js only and CSS for the mobile-looking app.
If not because of a concrete requirement, IMHO your best bet is to have just one very good, flexible and opinionated framework (personally I prefer ember.js) and create the modules you mentioned with your only choice.
Hope it helps.
As of now we can say that most of the applications are forced to put in more effort in its UI/UX and hence the dependancy on server side is becoming very less.
I have personally used backbone for my latest work and this has been great. The speed of the entire application can be noticed from the beginning. Ive been using PHP for the past 3 years and i can definitely vouch that backbone and other MV* frameworks are better.
Combined with CSS frameworks such as bootstrap, backbone can be an extremely organised and elegant applications.
All said, getting your head around models,views,routers,collections can be a headache. This is something which has vast possibilities and its only getting started.
Ive compiled a tutorial based on lots of tutorials present and has published at http://goo.gl/nJumC.
So many video tutorials are also available.
Only per-requisite is that one should have good knowledge of javascript and jquery methods and functions. Beginner knowledge in these will only make your task of learning backbone difficult.
Oh yes. I got my answer.
From google groups:
I think one of the reasons is javascriptless user-agents — i.e. search
engine crawlers and users with NoScript turned on.
I hope, these are real problems why websites still using Server Side MVCs.
When websites don't know target audience, they can't predict how well it will run on client side. So they should rely server to build much of their content.
And think, if stackoverflow was designed using client side MVC's to build much thier content, no one can't reach stackoverflow posts using google search.
From wikipedia under "Search engine optimization" section:
Because of the lack of JavaScript execution on crawlers of all popular
Web search engines, SEO has historically presented a problem for
public facing websites wishing to adopt the SPA model.
I think that is the shift we are heading now; I am not really sure about you but I noticed far more Client Side MVC Web sites. Anyways, you can also take a look at this ....
http://backbonejs.org/#examples
in my view, except the learning curve, it is pretty neat to develop using Client MVC and Web APIs using JSON/REST
I was wondering this for quite a while and haven't really found an answer for this yet.
Why would you use Backbone.js exaclty inside a Rails application? Is it to extend functionality, have a more MVC pattern for your JS, build better API's...?
At the moment I can't see a reason why you would want to use it for something, because I don't think I understand the concept of Backbone.js
The big advantage of rails is that you have one platform and one language that you use that will handle the server-code and can generate the client-code (using the views).
Undoubtedly this theoretical advantage quickly starts slipping once you want to improve your user-experience with javascript and jquery. So actually you still have to learn two languages.
But still: all your models, business-rules, ... is handled on the server-side in Ruby. This also means that the server always has to be reachable.
What a javacript/client MVC (like Backbone.js, Sproutcore, ...) can offer you is a more native application feel. A single web-page application, like e.g. Gmail.
Depending on your requirements there are some very valid use-cases for such a platform. E.g. in places or devices with low connectivity it could be very useful (with HTML5) to have a web-application that does not need to be "online" all the time. It could save data and edits to the local storage and sync back to the server/database when the device is back online.
But, there is a big disadvantage when developing client MVC applications in combination with Rails: you will have to do some double development (it is the same when you are using flex/silverlight). Your models will need to be defined both on the server and on the client. I can imagine that some improvements could be made, like on the client MVC you are actually using presenter-classes, which on the server-side could be stored in different models/tables. But still there will be duplication of logic, models, ...
So that's why I think that for most applications, at the moment, it is not wise to switch to some client MVC framework. It will be a lot more work.
But when you do need the look and feel of a real native application, or a one-page-web application, then a javascript client MVC framework is the way to go. And if you do need a client MVC framework, I would propose Sproutcore.
To simply ajaxify your current rails application (reduces load-time of every single page), take a look at pjax-rails.
(better late than never - hope this is useful to someone)
The description on backbonejs's website seems like a lot of words thrown together without much meaning. There is a big hype around it but what's all the fuss about?
The premise behind backbone is that modern day, single page web apps (think gmail) quickly become a very complex interaction between syncing dom elements, UI events and the backend. You could easily find yourself storing data within the dom elements, and then having to somehow extract the data again to update the database. If you don't structure your code very carefully, you'll quickly end up with spaghetti code full of complex bindings, or code without backbone.
Using backbone's models, collections and views gives you a well thought out structure to work within, allowing you to build large apps without being overwhelmed by their complexity. What's more, it ties in beautifully with a restful backend.
Is it common practice for people to NOT use rail's built in support for ajax? Or is it very flexible and it can really help speed things up and there is no need to go custom?
If by ajax you mean ajax view helpers, in rails 3 they are implemented quite well, and there really isn't a reason not to use them. If you mean RJS, it is a much faster way to get stuff done, but if you want to build highly dynamic and responsive interfaces, there is no shortcut to writing the javascript yourself.
Rails 2 was heavily tied to Prototype and was pretty obtrusive; it seemed a lot of people didn't use. Rails 3 is far more unobtrusive and framework-agnostic, and I expect it will be used a lot more.
Let me put it this way..
Using built in ajax functionalities will will save lot of your time and get your app up an running with no-time. But the problem is once your app starts growing and when you need more and more cool ajax features, its hard to manage.
Another thing is, If you are working on a team and there are UI designers to implement UI. sometimes they find it difficult to deal with built-in rails ajax functions. As they prefer go with pure Ajax framework and HTML.
Basic concept here is to let the UI designers to implement a user friendly interface while rails supports back-end features
** I really like the rails3 approach of Unobtrusive javascripts. which makes the clear separation of java scripts and server code
So as a sum up - Its all depending on the requirement. If you are looking at a small scale project with defined ajax functionalities you may go with default rails ajax support.
But if your app will grow and if you want to continuously implement your user experience its a good idea to have your own custom ajax implementations up on proven framework like jquery
cheers
sameera
I am not sure what you mean by built-in support for ajax. Because Rails has very good support for Prototype and jQuery.
But in rails 3 there is (good) push towards unobtrusive javascript, and that is indeed imho what most people do.
If you are talking about rjs, generating javascript with ruby code: that is imho best avoided. Sometimes it is good to get you started, and doing things unobtrusively is sometimes a bit harder at first, but it is generally much better.
The rant against rjs: it is not unobtrusive, you mix two languages, it only works for very straightforward cases (granted most cases). But because you can't do everything with rjs, there is bound to be a need to let some 'real' javascript slip in.
At first i really liked rjs: one language to do everything in. Until you discover the boundaries, and then you are stuck.
So i would suggest, for anybody new beginning in Rails: skip rjs. It will help you in the long run. Do javascript unobtrusively.
It is the same division in CSS: you want all your stylistic definitions separate from the content. Well, actually in js you want the same: you want your behaviour separated from the content. This makes for very clean HTML, clean CSS and clean js.
I'm building a new front end for an existing forum project, and I'm undecided on the best route to take for the user front end. The project will be built in ASP.Net 3.5.
The requirements are as follows:
1) User selectable themes/templates must be supported - I have forum goers who will want to contribute forum themes, so the layout system must be flexible.
2) Mobile friendly. The site must be usable from the most popular mobile browsers, so I have to be able to substitute templates based on the user agent and/or site url.
As near as I can tell, these are my best options:
1) XSLT: Output all of the relevant data in XML format, and dynamically attach an XSL stylesheet based on user settings/mobile state. I'm unsure how well mobile browsers support XSLT, but it appears that at least some do.
2) MVC: Sub in a different view based on user settings/mobile state. This might be harder to support templates from users, however.
3) Pure CSS: Standard DIV+CSS style layouts, subbing the CSS stylesheet in based on user settings/mobile state.
I'm quite sure that all of these options will work, however, I have only a basic familiarity with MVC, having developed exclusively in WebForms until now.
I'd love some guidance here, before I end up down the wrong path.
I would go for pure CSS layouts. It is increasingly being supported by more and more browsers.
I can't comment on MVC - no experience with that.
XSLT is something I like a lot. I don't know about mobile browsers, but it certainly is well supported by major desktop browsers (by supported I mean XSLT 1.0 is well supported). The downer is that there seem to be relatively few people with skills - much less so than CSS. So if your goal is to get reasonable abount of user contributed themes, I think that would be much better achieved with CSS.