Re: [gnome-db] Re: question: in memory table representation: please help

[Daniel Espinosa Ortiz <esodan yahoo com mx>]

Please, check for QOF and DWI for information about a librarys doing
some thing like you want.

http://www.gnucash.org/
http://dwi.sourceforge.net/
http://qof.sourceforge.net/

And my post: "[gnome-db] DWI, QOF and gnome-db"

May can help you, or orient, or better you can help in both proyects
(GDA, DWI and QOF)... I don't know, may be.. 

El vie, 29-10-2004 a las 22:49, Neil Zanella escribió:
> > On Wed, 2004-10-27 at 16:07 -0600, Neil Zanella wrote:
> 
> > so, what are you exactly trying to do? Why do you want that in-memory
> > representation of the table?
> 
> Because I'm writing a very special library to do something never seen or done
> before... it's somewhat complicated to explain, but I will try...
> (right now it works
> quite well, just that it's not implemented as a library) :-)
> 
> --- BACKGROUND ---------------------------------------------------------
> 
> The name of the new library, libsqlui, comes from the fact that its users, whom
> will be aquainted with XML and SQL, but not necessarily C, use three XML
> files to build the specifics of their user interface. The three files correspond
> to the three parts of MVC. The library I am building aims at building a generic
> controller with pluggable methods customizable via an XML file.
> 
> The controller allows the user to relate generic database tables to the user
> interface by interrelating data and widgets by neat of neat and clean API.
> 
> Basically, I'm taking some of the burden from the C of MVC off the user's
> back and plugging it in my special library.
> 
> ----------------------------------------------------------------------------
> 
> So, I need an in memory representtion of tables, cause these will allow
> my library to construct them so it can talk with my users. My users will
> be specifying table representations more than anything else when
> building their GUIs. (BTW, all of this is already done basically,
> just needs to be cleaned up, and moved to GNOME-DB for
> maximum portability. It just seems to me that libgda is the
> best choice for the task at hand. Just that I don't know
> how much of what I need it's going to support, but
> whatever is missing I'm gonna have to recode
> myself. There's not much to debate here: I've
> already built the system and it works, and is
> as a matter of fact a pleasure to use, but
> now I want it to make use of libgda.
> 
> > If you want to get data from a database, use the gda_connection_*
> > functions, no need to deal with GdaTable, which is only, as you noted,
> > an in-memory representation of a table. You can either create it from an
> > existing GdaDataModel (gda_table_new_from_model), or create it by hand,
> > in which case you need to add all fields, set all attributes on the
> > fields, add the data (gda_data_model_append_row), etc
> 
> I plan to let my library call those functions so the user of my library
> dosen't need to worry about much programming at all: the user worries
> about concepts, and the library carries out the specifics. ;-)
> 
> Actually, it's not as complex as it sounds... I'm just exploiting the power
> of generic programming in an area where it has not yet been applied.
> 
> --------------------------------------------------------------------------------------------------------
> 
> So please let me know whether I can access libgda's in memory table
> representations (in which case, please let me know how to use them),
> or whether I should reinvent the wheel.
> 
> Thanks,
> 
> Neil
> 
> P.S. my library is going to be open source and will accomodate behavioral
> patterns conceived by other users so long as they can explain them and there
> are enough developers willing to code them.
> _______________________________________________
> gnome-db-list mailing list
> gnome-db-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-db-list
-- 
Daniel Espinosa Ortiz <esodan yahoo com mx>