Whether or not to use an application framework depends partly on the scope of the project, and partly on your own software development style. Not to be pedantic, but even .NET, which was suggested, is a framework, not a programming language. What a framework buys you is a richer set of features and more reliable, maintainable code than building a whole app up from code. I do agree that for small scale projects, a framework is overkill. But for larger projects, relational data, user account management, real-time database integration and other complex features, a framework give you reliable, tested, maintainable features much faster than building them all from scratch. Sure, I'm a Drupal fanboy. But Drupal does support rich JavaScript and AJAX through jQuery, and even supports Google Gears ( http://drupal.org/project/gears) so it can help you out on the way to building a nice, responsive web-based application, if that is what you need. Whether you need a framework a just a bunch of code really boils down to the scope of your project and your own development style. Cheers, Curtis On Thu, Sep 11, 2008 at 1:28 PM, Tom Penney <tpenney at gmail.com> wrote: > It does not *need* to be a browser based application. If I were to > start from scratch that is how I would do it. There lots of advantages > and disadvantages to a browser based system. The biggest disadvantage > is the latency. To get fast at data entry you get into a mindless > machine like rhythm, the variable latency you see in browser apps > disrupts that, quite annoying to the point of not being workable. > > I was really hoping to find some type of existing solution i could use > without a lot of development. but the systems I've found are not that > great, and pretty expensive. > > If it were browser based it would have to have ajaxian features for > the on the fly lookup of entered items for auto filling addresses, > names and other validation. > I was looking into google gears because of the built in client side > data caching in sqlite. the user could submit and move on without > waiting for the post to the server. heres and article about gears and > data entry > > http://www.onlamp.com/pub/a/onlamp/2007/07/12/the-power-of-google-gears-part-2.html?page=1 > I haven't workd with gears but I'm guessing there would be a nice way > to preload the large images that the user enters off of. you don't > need gears to do any of this but it certainly looks like it would be > helpful for a project like this. > > The forms themselves are 2 page forms with several addresses which can > be looked up in a database of known addresses or entered from scratch. > other format validations have to occur, nothing too complex. The > images are large (2000pixels wide) and often hard to read so the user > has to be able to zoom and move the image quickly if they need to. the > images should move to the right position as the user moves from field > to field so that they are not spending a lot of time scrolling around > the image. > > I've built similar but simpler systems in the past, this would tame me > about 3 weeks I think. > > currently is stored to a database and exported to csv for import into > a different system. > > - Tom > > > On Thu, Sep 11, 2008 at 12:01 PM, Chris Barber <stuff at cb1inc.com> wrote: > > Why do you *need* Gears? I don't see how it would help in a data entry > > application. > > > > How complicated is the data entry? Is it like a rebate form (couple easy > > fields) or like an benefit enrollment form (employee info, spouse info, > zero > > or more child info, varying length of items)? Where is the data going? > > File? Database? Is there any special formatting to the data? > > > > As for some of the other responses, I don't think Drupal is the right > tool > > for anything other than eating up CPU cycles and bandwidth. There are > lots > > of things that can be done to speed up a web app and the web app can be > made > > to be as secure as the weakest password. > > > > If you needs are relatively simple, take a look at the Forms > functionality > > with Google Docs. Once you define the form, any submitted forms get > dumped > > into spreadsheet that can be exported to .csv, .html, .ods, .pdf, .txt, > and > > .xls. > > > > -Chris > > > > > > > > Tom Penney wrote: > > > > Forgive the off topic post. I was hoping that someone might have some > > advice for me. > > > > I've been handed a home brew data entry system written in VB6 that is > > in need of replacement. Code is poorly commented and the guy who wrote > > it can't be found. What I would LIKE to do is start from scratch and > > write a nice browser based system using google gears or something like > > that but I don't have time. I would think there would be a ton of > > stuff available, open or otherwise, as we are not doing anything > > unusual. But what I've found seems antiquated and expensive. I was > > asked to evaluate some Viking Software stuff which has the features > > that we need but, man, low tech, 8 character file names, keyboard > > overlays required, etc. > > > > We process about 10,000 hand written forms a month entered from > > scanned images on screen. Each form is entered twice by separate > > people and compared for accuracy. some fields are looked up in a > > table to auto populate other fields which can then be accepted or > > edited. nothing to fancy. Has anyone here run across anything I should > > be looking into? > > > > > > > > > > -- > Tom Penney > 612-920-3562 > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20080911/e3769e47/attachment-0001.htm