I'm guessing from your mention of 20+ years experience with things like delphi, MS Access etc that you may be misunderstanding the layer that storm operates at. Storm is a thin layer over writing SQL yourself, your questions could be directed to the postgres mailing list and make similar sense, "I know this 'sql' is great, but how do I hook it up to wxWidgets?"
The way you 'hook it up' to your gui is by writing a program, storm provides a data layer you can use in your application, personally if I wanted to write a GTK app that used storm I'd grab a framework like twisted, but thats really up to you, your project requirements etc. good luck -tjs On 7/12/07, AlphaCentauriSoftware <[EMAIL PROTECTED]> wrote: > Hi everyone: > > I just joined the storm mailing list and saw the email below from Stuart > Bishop. > > When I first saw storm being mentioned and checked out the tutorial I got > really excited. > > however, it didn't last very long. (yes, yes, i know storm is just an infant > and things need to be put in place) > > I have been programming database applications for almost 20+ years and > wanting to get away from delphi, visual foxpro and microsoft access; so i > started looking for more info on storm--even googled it to disappointment. > and that's why i joined this list. > > The first question that came to my mind is how is storm going to help me? > Although the tutorial on the storm page showed me examples (which got me > excited seeing its simplicity), I couldn't find answers about how can i code > these features into an app. I only understood it to be a data store, but how > do I implement it? how do i wire it up with an interface for end-users? > > to add to stuart's questions: > > My questions would be like: > > -- what widget system would i use to work with this store? wxWidgets, Qt? > examples please... > -- how would i populate these widgets with data from the data store? > -- how would i make the widgets data aware? > -- how would i commit the data updates in the widgets? > -- how is the store used to refresh pagination in a datagrid? > -- can the store cache be used offline and then subsequently be used to > update the backend db? > -- is the data store synchronized with the db? if not how do we check before > committing updates? > -- how are database error messages handled by the store so we can inform > users in the client application? or decide upon a course of action. > -- how do we work with stored procedures at the back-end db? > -- etc... > -- python is cross-platform, but what is the store's compatibility with > win32, gtk, kde? what are the nuances? (surely, i'm gonna get shot here by > someone on the list as a stupid question) > > whatever stuart says below is great, it throws a lot more light on storm. > > my questions however start from the view of a person actually coding a > database app and how to wire it all up? > > i'm still excited about storm and hope this is what database app programmers > are looking for. thanks for the great job done. > > best regards > ram sambamurthy > kuala lumpur, malaysia > > PS: i'm subscribed to the digest so it becomes a little difficult to reply. > pardon me if i'm not following any protocol such as replies come at the end > and not at the beginning. does this list practice anything like that? > > ------------------------------------------- > Date: Thu, 12 Jul 2007 07:31:35 +0700 > From: Stuart Bishop <[EMAIL PROTECTED]> > Subject: More 'About Storm' > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="utf-8" > > I think there is more information needed in the About Storm section on the > storm.canonical.com front page. Something like: > > Storm is different to other Python ORMs: > > * Designed from day one to be database administrator friendly. > * Designed from day one to work both at the low end, with trivial small > databases, and the high end, with applications accessing billion row tables > and committing to multiple database backends. > * Designed from day one to work both with thin relational databases, such > as SQLite, and big iron systems like PostgreSQL, DB2 & Oracle. > * Distributed database integrity using two-phase commit (if your Python > driver and database backend support it). > * Storm does not dictate your datamodel. > * Storm lets you efficiently access and update large datasets by allowing > you to formulate complex queries spanning multiple tables using Python. > * Storm lets you fallback to SQL if needed (or if you just prefer), > allowing you to mix 'old school' code and ORM code > > These are all from my perspective, so may not be general enough for the > front page. Other people might have points or catch phrases to add too, but > we don't want the section to grow too big so high level points should > replace low level points. > > > -- > storm mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/storm > -- Timothy J Stebbing -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
