Personally I think a database should provide long-term storage for your application's state, not drive the application's UI. If you need to update views based on state then that state should be in memory with mechanisms to easily detect changes.
If you're too far along and need to use the database then you can at least partially handle updates outside the db. If you funnel all of your database calls through a central application interface then that can broadcast events to the rest of your app when something changes. Even if it's not detailed and watches only for insert/update/delete SQL and broadcasts a "something changed" event then you can query the db to see what changed and it'd be more efficient than constantly polling. HTH, Sam ------------------------------------------- We're Hiring! Seeking a passionate developer to join our team building Flex based products. Position is in the Washington D.C. metro area. If interested contact [EMAIL PROTECTED] -----Original Message----- From: Wesley W. Terpstra [mailto:[EMAIL PROTECTED] Sent: Thursday, February 15, 2007 9:33 AM To: sqlite-users@sqlite.org Subject: [sqlite] Triggers+callbacks = GUI? I intend to write a GUI application backed by SQL. Several of the windows display status that would best be represented as a database view. What I've been thinking about is how to update the GUI when the view changes. First the obvious approach: polling. Every X seconds re-execute the query and redraw the GUI. Certainly this will work, and I might still do this. For windows with very large state, however, this is not very desirable. ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
