I am developing an app which as I go is really an application development framework for building data driven applications. Maybe next time you guys meet I will bring it by and demo it. It's pretty cool in concept, but would need a lot of polishing to be usable as a general purpose tool. A couple major features include a database connection card, a dropField module which drops fields, buttons and menus based on a table from the database schema, and a validation module where you can enable and disable a series of validations foe each field.
Bob On Jan 6, 2012, at 1:19 PM, Richard Gaskin wrote: > Andre Garzia wrote: > > > On Fri, Jan 6, 2012 at 2:09 PM, Richard Gaskin wrote: > > > >> Many thanks to all who attended last night's LiveCode User > >> Group meeting in Pasadena. It was a lot of fun, and even > >> with all the talk of trains we managed to get some design > >> work started on what will hopefully be a new library for > >> the LiveCode community - more on that later. > > > > I am curious!!! what library??? > > A chunk of most of our meetings is devoted to kvetching about things we'd > like to see improved in LC, and last night Todd Geist noted the many times > newcomers use cards for data storage, make a standalone out of it, only to > later realize as a standalone it's no longer writable so it has to be > rearchitected. > > We looked at this from a variety of angles, and considered the strengths and > weaknesses of different ways to solve the problem, ranging from writing a new > Standalone Builder to patching the IDE to even writing a new IDE. > > But as we looked at the problem more carefully we began to realize that none > of those would solve the core problem, which is to keep user data storage out > the stack in the first place. > > So the problem became defined as: > > How can we provide the benefits of using cards for data storage > -- with First, Next, Previous, Last, New, Delete, and more -- > without actually using cards for data storage? > > Anyone who's worked with LC for some time has solved this problem in various > ways, and indeed there are a nearly infinite variety of ways to work with > externally stored data. > > The trick is to have one that's easy enough to use that newcomers will love > it, but which handles enough of a variety of data store types to make it > useful for experienced developers. > > Factoring code, data, and presentation is old hat, something we've all had to > learn at some point so we can update our apps efficiently. It's that latter > part -- supporting an unknowable variety of different data stores -- that was > the solution that came out of the meeting last night. > > More on that later. :) > > Today I have a client deadline to meet, but next week I should be in a > position to spend a couple hours fleshing out a prototype for discussion in > the Rev Interoperability Group.... > > -- > Richard Gaskin > Fourth World > LiveCode training and consulting: http://www.fourthworld.com > Webzine for LiveCode developers: http://www.LiveCodeJournal.com > LiveCode Journal blog: http://LiveCodejournal.com/blog.irv > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
