From: Kevin A. <al...@se...> - 2001-10-22 17:34:34
|
> From: Patrick K. O'Brien > > * Some kind of persistent data storage. A lot of apps don't need persistent storage. We should probably also make a distinction between the meta-data for widgets and the field/record data they contain. > If there is interest in this idea, here is what I think needs to happen: > > 1. Decide on a sample application that reflects the kind of app > people would > have done in HyperCard. That's part of the problem. HyperCard was a general purpose software construction kit that was used for all sorts of applications. Even things that couldn't be done well in it directly such as traditional BIG apps: Word processor, spreadsheet, SQL database, draw program, etc. people using HyperCard as a front-end if you will for BIG apps or used external code to do do stuff that HyperCard didn't have built-in support for such as a grid control (spreadsheet). However, HyperCard did impose enough limitations through its model and tools that for a lot of things it simply got in the way. I think this is what Rowland refers to when he says we should just abandon the HyperCard baggage. I'm pretty much convinced now that we should have a more generic model and then if we want to follow the HyperCard model later, it should be built on the more generic model. > 2. Decide how we are going to store the data - CSV, ZODB, XML, MySQL, etc. Initially, I would suggest an abstraction layer between the storage of data and meta-data and then use a backend that is easy to parse and manipulate with tools outside of PythonCard. That means not using ZODB or any binary storage format. The reason for the restriction is that until the model and interfaces settle down we'll have to muck about in the resource and data files, finding bugs, coding examples from scratch, etc. > 3. Develop the app in a collaborative fashion to get feedback > from more than > one person. > > 4. Document as much as possible so that this serves as a tutorial > of sorts. > > 5. Repeat for the next app until PythonCard is perfect. > > How does this idea grab everyone else? Good, bad, indifferent? If there is one app that will cover most of the issues you've brought up it is probably a contact manager like the addresses sample, but with more features. However, in order to generate more interest an app that manipulated and published web pages via a template system, outlines, whatever, would probably be a better choice. What did you have in mind? ka |