You may want to consider using Adobe AIR. It would allow for a host of benefits beyond what you could do with either Flex or Ajax. Just one possibility would be that you could use a local (to the workstation) database and the local file system. For example you could have a local clipart gallary that graphics could be loaded into for development and only uploaded to the final destination as they are actually used in the project.
You may also want to consider using ColdFusion rather than Ruby or PHP. (Though Ruby may also a good choice.) CF9 provides an ideal server side backend to Flex and AIR projects.
Thanks Joe for your valuable input.
Adobe AIR applications are deployed on the desktop. You're correct, they offer a clear advantage of being able to use local resources. My goal is to develop a website builder through which I can offer services similar to wix.com. The potential issues with approach can be:
1. Users may be unwilling to download an installer package compared to just clicking on a link.
2. From what I understand using Adobe AIR sets me free from the limitations of the browser and thereby gives me additional benefits. So a product which is deployed using AIR should work in exactly the same manner as it would inside a web browser. Now, the purpose behind building the website builder is to offer my users a simple solution to creating a website. BUT only so that it helps me sell my hosting services and other add-ons I offer in the package. I do not want it to become a standalone desktop application for general use. So do I need to do things differently if using AIR to prevent this from happening? OR to put this another way, how should the AIR app be designed so that the website builder is only useful to people using the services of my website.
I want a CMS which is compatible with Flex which is why I thought of Ruby on Rails. If I use ColdFusion, which CMS do I use?
Hi, Sorry for the late reply. I have been very busy lately.
In answer to your first psudo question, " Users may be unwilling to download an installer package compared to just clicking on a link."
True: But you can offer both. You can build the application in Flash and deploy it both to the desktop and within a browser. But you would not have access to the native OS's api's from the browser so you would have to put some thought into what you can sacrifice in the browser.
Also I have found that if looks good and functions well enough it's generally not difficult to convince someone to install an AIR application. Especially when they learn that they can use the application even when offline and then automatically syncronize their changes later when they can get back online.
Towards your second question: "how should the AIR app be designed so that the website builder is only useful to people using the services of my website."
That's pretty simple actually. You would design the AIR application to only connect to your back end services. AIR has built in database functionality where prepaired files can be stored. You do not have to give access to these files to the user and you could even encrypt them if you want. So they would not be useful to the user. When the user has a file prepaired they would simply have to login (connect to your server) and upload their modifications (or you could build a way for them to choose which files to syncronize). If they do not have access to the prepaired files and the only system that the AIR application is able to connect to is yours then they are pretty much locked into using your service.
Assuming your AIR application functions well enough, by having such a user friendly interface, your users will become used to it and anything else will simply no longer be good enough for them.
As for your choice of CMS systems to use that's entirely up to you. Ruby is also a good choice. ColdFusion is just (in my opinion) much easier to use and requires less code overall. There are several good CMS systems built in ColdFusion that you could choose from. Just do a google search on Coldfusion CMS and take a look at what's out there. There are several opensource projects that are very mature. The downside is that the best of them are generally built around one of the more popular coldfusion developer frameworks. Though this is actually a good thing it does add to the complexity of the system if you are totally new to ColdFusion and as such adds to the learning curve.
If you already know how to develope in Ruby, learning ColdFusion may not be something you want to do or have time to do. So in that event I would stick with Ruby and look into use Blaze DS with it. If you have the time though learning ColdFusion is well worth the time and effort.