views:

83

answers:

1

I am working on an application that will have online and offline components and would like to get some opinions on how I am planning to do this. Feel free to give me some tough love if this is a ridiculous idea as I would like to learn as much as possible with this :o)

Here are is an outline for what I am trying to accomplish...

  • Client portion does basic CRUD, but forms may change depending on what is in the online database.
  • Client portion can be used online or offline.
  • Client portion should be fairly easy to move from one machine to the next (ie I'd rather not have to set up a database on each client).
  • Server portion does not need to be synched in real time.

I'm considering making the client portion a series of HTML forms that read from and write to cookies. The forms will be generated using JS based on what is in the cookies. For example, a cookie may store things like a list of values that will be used in a select box on the form. When the forms are submitted they will write to cookies. The forms could be used to submit data that will likely change how the form is generated next time it is loaded... for example, I may have a form that will allow me to enter options that will be included in another form's select box.

The server portion will read these cookies, update the database and then update the cookies so that the forms are appropriately generated next time.

Does this sound nuts? Would I be better off looking in to something like Google Gears? Any tips, advice or ideas would be greatly appreciated!

Thanks in advance :o)

+1  A: 

Unless the online/offline thing is what will distinguish your application, I'd let Gears handle this. The general advice is to focus your effort on the parts of the functionality that distinguishes you, and let libraries handle the rest—assuming they handle it in a way that is acceptable for your app.

Hank Gay