Le mer 22/01/2003 à 01:47, Rodrigo Moya a écrit : > On Tue, 2003-01-21 at 20:46, Santi Camps wrote: > > > > I like it. Perhaps it could be usefull for a lot of users some way to > > generate this query-map from the tables and relations structure, or > > something like this. > > > oh, yes, this is also madatory, IMO. We should make use of the nice > ObjectSelector widget in Mergeant to allow the user to select the tables > and fields for the query, so that they don't have to enter at all any > SQL. I agree with the idea that the user must not need to know SQL at all to use mergeant (well of course if he knows it it's easier). Also I have an important remark about using tables and queries for database exploitation (when creating reports, exports, doing data edition, data visualization, etc): I prefer to always use Query objects for two reasons: first it is easier to deal with only Query objects than with both Query and DbTable objects, and second because if the user wants to start with something simple, he creates a simple query (SELECT * from mytable) and when he wants to do some more sophisticated work, he only has to modify the Query (and he does not need to create a new query to replace the table he used previously). So the idea is only work with queries (the Query object) for additional features in mergeant (and if a table is needed, then create a query for "SELECT * FROM table"). Taking into account the remark above, here is the architecture I propose for the reports in mergeant (and which integrates with the existing mergeant's architecture): -> add a simple function to create a Query representing "SELECT * FROM my_table": a button in the list of tables tab. Creating such a function is already available today but the user must click on the "new query" button in the queries page. -> create a new GnomeCanvasItem to represent a Query object on a canvas: a CanvasQuery object (modeled for example after the CanvasQueryView). This GnomeCanvasItem will: - show the fields in a query - show the parameters of a query -> create a ReportView object (inherited from a GnomeCanvas object, similar to the CondsView) to display CanvasQuery items and enable connection between them as shown in the proposal I sent yesterday. -> extend the DTD to store reports definition (queries and their relations, text, etc) and write the actual code which does the job of generating a report description which can be sent to libgda for "interpretation". I know this is quite a lot of work, but then we have something quite generic which uses the power of the Query object. Tell me what you think about this. I've reworked a bit yesterday's proposal about the GUI for the reporting tool, see the attached file. Cheers, Vivien
Attachment:
report.dia
Description: application/dia-diagram