[Qgis-developer] RFC vector data providers handling

[Marco Hugentobler]

Hi all,

I also think it is good to unify provider properties at the GUI level and, as 
you mention, it is certainly a good idea that all providers benefit from 
concepts like subqueries and creation of new data sources.

> > > Each data provider should have a private list of connections (ie.
> > > database connection in PostgreSQL, datasources in OGR) and offer class
> > > methods to
...
> > > - add and edit new connections (this would include a provider specific
> > > gui), - return a list of datasource with the available vector layers

> And the vector data providers might need and additional method to fire
> up a gui to set a filter (ie. QgsPgQueryBuilder for the postgres
> provider and something similar for OGR layers that support it).

One thing that in my opinion is important to consider is to keep GUI and 
references to dialogs out of the provider classes.
A possibility might be to have a specific dialog class for each provider that 
is able to create a provider from GUI input. Like this the dialog knows about 
the provider, but not the other way round.

I'm trying to have a closer look at Juergens patch in the next days and 
possibly will then have a more complete understanding of the proposed 
changes.

Regards,
Marco 

Am Dienstag 22 April 2008 19:37:09 schrieb Jürgen E. Fischer:
> Hi Godofredo,
>
> On Tue, 22. Apr 2008 at 15:57:10 +0000, godofredo contreras wrote:
> > Yes, I also think that  notation should be private to the provider.
> > This way we can add new types easier without touching any other
> > code(OGR case).
>
> Or every other provider.
>
> > > In the process QgsDbSourceSelect should be renamed to QgsSourceSelect.
> > > The gui should list should list the registered vector data providers
> > > (classes).
> >
> > I was thinking a little about this and I think we can unify raster,
> > vector (file based) and vector(database based) and even wfs and wms in
> > a dialog. This way we can simplify a lot the gui.
>
> I just thought (and cared) about vector layers yet, but your right.
> QgsProviderRegistery doesn't make a difference there.  We can take it to
> the QgsMapLayer level.
>
> > > Each data provider should have a private list of connections (ie.
> > > database connection in PostgreSQL, datasources in OGR) and offer class
> > > methods to
> > >
> > > - list connections by name,
> > > - remove a connection by name,
> > > - add and edit new connections (this would include a provider specific
> > > gui), - return a list of datasource with the available vector layers
> > > through a named connection (ie. layers in OGR, geometry columns in
> > > PostgreSQL).  To support provider specific grouping (eg. for schemas in
> > > the PostgreSQL provider) that could be aggregated in a QDomNod.
> >
> > Have you thought about the layer creation? should it be included in
> > provider?
> > How will we access the new functionality in the provider? do the
> > interface needs to be extended?
>
> Above is as good as a list of methods I'd like to add to the providers.
> I intended to add class methods.  But we could also add and export
> functions (or wrappers for the class methods;  similar to
> fileVectorFilters()).
>
> QGISEXTERN QStringList getConnections();
> // would return a of registered connection names in the driver
> // QgsSourceSelect would call it to fill the connection combobox after
> // the provider is selected. This should also get an "New..." entry.
>
> QGISEXTERN bool editConnection(QString connection);
> // would be tied to the add/edit button and add/edit a selected
> // connection in the combobox and open a provider specific dialog box.
> // That gui could optionally include and "Add Layer..." button to create
> // a new layer (ie. QgsGeomTypeDialog for OGR, but not tied to just
> // shapes).
>
> QGISEXTERN bool removeConnection(QString connection);
> // would be tied to the remove button to remove the connection
>
> QGISEXTERN QDomNode *getLayerList(QString connection);
> // would be tied to the list layers button (to replace "Connect")
> // and return a list of layers that is used to fill QgsSourceSelect
> // lists layer list.
>
> QGISEXTERN QgsMapLayer *getLayer(const QDomNode *);
> // would instantiate a QgsMapLayer with a selected layer
>
> And the vector data providers might need and additional method to fire
> up a gui to set a filter (ie. QgsPgQueryBuilder for the postgres
> provider and something similar for OGR layers that support it).
>
>
> Jürgen
>
> --
> Jürgen E. Fischer         norBIT GmbH               Tel. +49-4931-918175-0
> Dipl.-Inf. (FH)           Rheinstraße 13            Fax. +49-4931-918175-50
> Software Engineer         D-26506 Norden               http://www.norbit.de



-- 
Dr. Marco Hugentobler
Institute of Cartography
ETH Zurich
Technical Advisor QGIS Project Steering Committee