views:

109

answers:

2

I have always written websites that interact with the endusers directly.

Now I want to create a website that lets users create their own websites - from scratch.

Almost like Drupal online, I provide all the unit blocks for them to use to build their own website. They just drag and drop text fields, buttons, (div) containers etc.

I have no experience with this and I wonder how an user's website should be stored in the backend.

I'm doing this with Sprouctore (Javascript framework for the frontend) and in the backend I run Rails with CouchDB. I'm going to use Heroku with this.

  • Should a user's website be one "application document" in CouchDB (so that I only have one Heroku application) or should an user's website be one heroku application, and thus if I have 100 users I will have 101 Heroku applications - one is my own main website for creating websites.
  • How do others do it? There are a lot of this kind of websites already.
  • Something I have to know before I start coding?
  • Tutorials/books for this kind of website create website programming (sounds like meta-programming would be something good to know)?
+1  A: 

if i were you, i'd research CMS applications, pick the ones I like, and investigate their code.

I have done this a few times (cms's, form generators, html template creators) and each time used a different approach. however it all comes down to separators,

suppose you are going to save an html with a dynamic title per client, <head>{{title}}</head> u need to pick something that never gets mingled with any type of content, and you can store it in pretty much any database.

my advice to you is, create 5 different html versions of the sites you will let your clients create using your UI, let those pages speak to you. And one data structure you will use a lot is 'tree structure', that's probably it.

Coming up something like this is a lot of work, but it's def no brainer. You'll figure it out very quickly.

Devrim
+1  A: 

Should a user's website be one "application document" in CouchDB (so that I only have one Heroku application) or should an user's website be one heroku application, and thus if I have 100 users I will have 101 Heroku applications - one is my own main website for creating websites.

You can choose either options:

  1. Application per user - good for isolation, harder to manage, provision and maintain.
  2. Single application handling multiple users - generally easier, might require a single database. Harder to scale.

How do others do it? There are a lot of this kind of websites already.

Why can't you just look at the code of OSS project? Dupal, RadiantCMS, DNN etc - there's shit load of them.

  1. You need to handle (wildcard) domains from your rails apps (enough info on the web for it).
  2. CMS is a pretty tough thing: CMS Problems.
  3. Application that builds application is a myth. Many companies come close to it, but still not enough.
  4. The resulting page has to be built from different parts that user uses and configures. Possibly cached.
  5. You will have to manage assets like images, videos etc in an easy way (which is also pretty hard).

Something I have to know before I start coding?

You need to know what you want the website to do for you :)

Technical things from the top of my head are:

  • How to edit pages/content/parts (~>2 separate modes or all in-place)
  • How to control access
  • How to build menu, navigation, breadcrumbs
  • How much to allow a user to work with HTML/CSS/JS
  • How to support templating/skinning
  • Read through the CMS Problems
  • Pre-processing of the HTML before rendering

Tutorials/books for this kind of website create website programming (sounds like meta-programming would be something good to know)?

Nothing really to do with meta-programming (unless you want your users to be developers).

Not about the books, but you can first have a look at A CMS in Ruby on Rails, and Why I Stopped

Hope that helps.
Cheers.

Dmytrii Nagirniak