<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'><div style="text-align: left;"> The idea to keep qgsdatabaseconnectionbase and qgsconnectionmanager is to reuse<br>this classes in the refactoring of spit and for the ogr plugin(layer cretion and utilities), If we move them to app <br>how could we call that classes?<br><br> Also I was thinking in using a similar aproach to QgsVectorLayerin QgsDatabaseConnectionBase but<br>checking the code I saw that QgsProviderRegistry::instance() gives access just to provider class not to other<br>classes compiled in provider(assuming that we move qgspostgresdatabaseconnection and qgsogrdatabaseconnection to their respective<br>provider), do you know if there are a form to access other classes in the provider in runtime?<br><br>Regards<br>Godofredo Contreras<br></div><br><br><br><hr id="stopSpelling">> Date: Wed, 7 Nov 2007 22:39:53 +0100<br>> From: wonder.sk@gmail.com<br>> To: frdcn@hotmail.com<br>> Subject: Re: [Qgis-developer] [QGIS Commit] SVN [godofredo] r7284 - branches/ogr-plugin-branch/src/app<br>> CC: qgis-developer@lists.qgis.org<br>> <br>> Hi Godofredo,<br>> <br>> On 11/7/07, godofredo contreras <frdcn@hotmail.com> wrote:<br>> ><br>> > Hi Martin:<br>> ><br>> > I´m working in fixing the dependency introduced by the files in dbutilities<br>> > of core<br>> > what do you think about this organization of files in dbutilities:<br>> ><br>> > qgsurimanager will be deprecated and qgsdatasourceuri will be used<br>> > qgsconnectionmanager has no extra dependencies and could be kept in<br>> > core/dbutilities<br>> > qgsconnection has no extra dependencies and could be kept in<br>> > core/dbutilities<br>> > qgsdatabaseconnectionbase is used as an interface for<br>> > (qgspostgresdatabaseconnection and qgsogrdatabaseconnection) has no extra<br>> > dependencies and could be kept in core/dbutilities<br>> <br>> OK, looks good.<br>> <br>> > qgsgeomcolumntypethread and qgspostgresdatabaseconnection are postgres<br>> > specific (not really sure) if they are moved to providers<br>> > then I need to add a dependency in app to postgres<br>> > provider<br>> > qgsogrdatabaseconnection is ogr specific, same case that the above one<br>> <br>> postgres stuff must really go away from core lib. Ogr stuff doesn't<br>> matter as we depend on it already.<br>> In fact, in my opinion I would prefer to put this all to src/app. Once<br>> stabilised completely (API-wise) we can decide to put it to core<br>> library. Or is there any reason why it must be in core library?<br>> When postgres support is enabled, qgis app also links to postgres<br>> library, so you could eventually leave QgsPostgresDatabaseConnection<br>> there (with #ifdefs to ensure that it won't be compiled with postgres<br>> support off).<br>> <br>> However these all problems say that our design of providers should be revisited.<br>> <br>> Martin<br><br /><hr />Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! <a href='http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews' target='_new'>Try now!</a></body>
</html>