I developed an App with Rails 3.2
We realized that we may end up having many 'standard' content pages, mainly text documenting the application itself. Nothing the application users will be playing with.
Is there an extension (plugin, gem) I could use to add page to my app like we would normally do on a standard CMS?
I want to be able to delegate the addition/nodfication of content to the admin rather than coding it in HTML.
We had a similar problem with our knowledge base, and chose to use nanoc for it.
This gives us something similar to developer.github.com in term of end-user. And the code is written in markdown (developer.github.com is open source).
This way, all our documentation is written in markdown in static files.
Support people can write them without having to know about programming. With the GitHub Mac App, they can very easily push and pull from a repository.
Related
I've been using Ruby on Rails since a little more than one year now and I've always do it in a casual way, I mean, everything in one place (front & back), using the standard .html.erb file populated by the associated controller method.
Otherwise, today in our project, I have the need to separate the front and the back end for multiples reasons (code maintainability / clarity, better architecture, more reactivity, etc...).
I've done plenty of researches, watch some conferences (1, 2, 3), but didn't find my solution yet. It looks like to be a question that comes often, but what is the best practice/tools to separate the backend and the frontend of a Ruby on Rails app?
I don't feel we need (yet) a huge JS framework like React/EmberJS/Angular/etc...
First I was thinking about something like Middleman/Jekyll and make the communication via JSON and API calls, but it seems like that it's not a good solution for dynamic website.
So is there a frontend framework that works well with a Rails API and which is easily maintainable and upgradable (add feature/extension to it like gems)?
Thanks for your insights.
A friend of mine wrote this great article/tutorial on Rails as a backend API.
http://blog.launchacademy.com/the-basics-of-building-an-api-in-ruby-on-rails/
As well as this tutorial on Rails/Ember.js
https://github.com/diegodesouza/Project-Planner-EmberJS
You can get an idea of how it's done and implement your preferred front end framework.
Hope it sheds some light on this question.
I have a similar setup as one of the commenters on the question.
I'm using Rails mainly for just the project structure, to define some page layouts, and for ActiveRecord.
I then have my JSON APIs defined using the Grape API framework.
I have a SPA, written on AngularJS that lives in the public/ folder. It doubles as my mobile app, made possible by phonegap. If my Angular app didn't double as my mobile app, I could've possibly just used the asset pipeline to serve up the SPA. To compensate for that, I have a separate build task written in Grunt to minify/uglify my JS/CSS assets before I deploy them out to production.
I also use Comfortable Mexican Sofa for my static content pages.
It took some trial and error to get things right, but overall I find that this setup serves me pretty well.
I am wondering if there is a standard pre-built web application for Rails which has all the basic functionalities like user login, user profiles, profile image uploader, comments, search, maybe payments and a set of other usual web application features all bundled and ready to use and extend.
I like how Twitter bootstrap comes with a set of pre-built interface functionalities and styles, which you can start using and modify later. I am looking for something similar that can allow me to quickly set up a working application and go from there.
Does such a framework exist?
There are numerous examples out there.
However, there are two things you should really do:
Read the license to make sure you can use it they way you are thinking of using it.
Ensure you understand the design decisions and choices the original authors made. You will end up in a world of maintenance pain if you just copy cargo-cult style without understanding the tradeoffs others have made with their design decisions.
Any one of the links listed has enough to get you started. They may not have all of the features you listed but together they probably have all of your bases covered. You will have to put in some effort to get all those features working together though.
The RailsApps project is great because they all have tutorials that walk through the basic setup. They are also all built using the Rails Composer tool, which lets you pick and choose certain options for your app.
So, we want to rearchitect a portion of our site as a Rails app. The original plan was to have a main "site" app, with a number of plugin apps (Rails 3.1 Engines) with compartmentalized functionality -- a store component, a social/forums/chat component, etc. Also, we wanted to put themes/styling in a gem so that our web designers could modify the site appearance and some minor layout tweaks without having to "know Rails." Initially, this was going well; we created the main architecture and plugins and the theme gem, and it was all playing nicely together; cross-cutting functionality like auth was put in the main "site" app and was consumable by the plugin apps, giving us a single sign-in for the site (a design requirement).
Our initial plan for the store component was to use the Spree (http://spreecommerce.com/) since it had, out of the box, 95% plus of the functionality we needed. However, there's a catch -- Spree is distributed as a mountable engine, but it's also an app. Meaning that not only does Spree mount inside an app (which is not a problem, in fact it's behavior we were counting on), but it depends upon being in control of the main app. Looking into the "why" for this behavior, it seems to depend upon two core pieces of functionality. The first chunk of functionality is some SEO permalink rewrite functionality that has to go into middleware; we could hack things so that our main app included this chunk of code (even though this would begin to entangle store functionality across our entire site, muddying the "Spree as a mountable engine" story... more on that in a moment).
More complicated is Spree's use of Deface to do theming and customization. While this is "clever" (note quotes), it really makes the integration of Spree kind of a nightmare; either you follow the path of least resistance and make Spree an entire store to itself (which completely breaks our story of "the store is just one part of our site, and plays nice with the rest of the site, including auth, theming, etc."), or you have to hack the hell out of Spree.
Not only that, but Spree doesn't follow the standard Rails Engine routing paradigm, where routes are isolated beneath an engine root (if you look in the lib's routes.rb file, you can see that it uses Rails.Application's routes, instead of an Engine's routes). This means that we couldn't have www.oursite.com/store/...all_the_spree_goodness, we'd have to have www.oursite.com/spree_owns_the_sites_routes...
So, has anyone else tried this? We LOVE Spree and would like to use it as our store. But it's starting to look that there's no real way to "integrate" it with the rest of our site aside from maybe some proxying magic with nginx or something like that (which is a separate nightmare, since we're hoping to host on Heroku, and then we have to figure out how to integrate multiple disparate apps into one DB -- for single sign-in auth -- and an HTTP front router).
Spree devs, we LOVE your code, but is there any work being done to make it an actual, for-real Rails Engine, as opposed to a stand-alone app that just happens to package all of its features into Engines? Without the ability to integrate it into an existing site (including not "owning" the app, being able to have all of its routes partitioned off, and so on), there's just no way we can use it :(
TIA.
I'm the Community Manager for Spree, so I think I may be able to answer your question.
Yes, there is work going on that will allow Spree to be a true Rails engine. In fact, that was my first task that I did when I was hired by Spree. The work is on the master branch (https://github.com/spree/spree) and we're looking to release this code as a 1.0.0.rc around Christmas time.
With this code, a couple of changes have been made. For starters, Spree is now a proper Rails engine meaning that you can now have it mounted at /spree or /shop or /whatever and Spree's cool with that. Secondly, all the models and other classes are namespaced so they won't conflict with anything in your application.
I'm not sure what you mean about Deface being "clever", though. What problems do you forsee with this? If you want to override an entire view you could do this by overriding the path in app/views/spree/products/show.html.erb. Mind you, this overrides the whole view, and if you only want to override a part of it that's when you'd use Deface.
Could you perhaps elaborate on the issues you're having with Deface? Would be interested to help you sort them out.
Thanks for using Spree!
I'm still implementing basic functionality in my app so I'm asking this now in case I need to re-think my design. My user interface in a "real browser" is a bunch of links which load data through AJAX. It also supports "normal non-AJAX" interaction. My controllers look somewhat like this:
if request.xhr?
render article
else
redirect_to article
This works very well so far and I have no problems. The problem is how I should add support for mobile apps. In the example above render article renders the file show.js.erb which looks like this:
$content.content("<%= escape_javascript(render "feeds/show") %>");
Obviously this won't do in a mobile application where I won't be working with a browser. I am thinkg of using phonegap to develop my app. I should note that I have zero experience with it.
So what I'm looking for is advice as how I should prepare support for a mobile application, any help is gladly appreciated. How should I be doing communication and are there anything special I should consider from hereon when I continue developing the backend?
There is an article about this. It's been written a few years back and uses IUI and Rails 2. The conventions in this article still prove quite valid in later versions of Rails.
However, the concepts of what is needed to get you started is explained therein. It speaks of using an app called iPhoney, which helps in the debugging stages.
Second, the article explains how one would be able to configure Rails iPhone mime type and how to detect iPhone user agents, among other setups as well.
If you haven't already. I would suggest looking at jQuery Mobile. Which may suit your requirements as well.
A more up-to-date article can be found here.
What editor can you suggest to integrate with the backend of the web app I'm currently developing? I want to allow my trusted users to add articles that would be visible on the
frontend. It should have some kind of markup language (to make basic customisation - lists, bold...) and if possible also the option to upload images.
look into restful_authentication (authentication), RedCloth (textile markup language), Hobo (admin interface), and paperclip (file uploads/attachments). You can piece together something with those.
If the editors of your site are not so technical, you might want to look into a Javascript markup editor instead, such as TinyMCE for editing articles - it looks similar to the gmail editor or the one here on S/O (bold / italics / etc), and you don't have to use textile markup.
You can also try routing to, say, admin/modelname, and create administrative controllers there. Hobo might be a way of doing it, but it is usually done manually.
I suggest using RedCloth for adding a textile style mark-up language to your articles.
I also suggest Paperclip for uploading & attaching images to your articles.
Do you mean "editor" in the sense of a component you present to end users in the browser, embedded in the Web page?
Stackoverflow uses the WMD editor. It's good. I'm using it in a current project. It took me about 20 minutes to read the docs and set it up. It's fast, lightweight, works in most browsers, and is easy to use both for you and the end users.
It uses the "Markdown" markup language.
Try Radiant CMS for a complete solution.