[news.eclipse.dtp] Re: Reusing the server explorer in a ContainerChecked

[philippe.girard@xxxxxxxxx (Philippe Girard)]

Brian Fitzpatrick wrote:

> Hi Philippe...

> That sounds great! We're always on the lookout for more help. :)

> Do you have a use case for this type of functionality? (I can see some uses, 
> but I'm curious what you see as the main goal of going this route.)

I didn't write a formal use case for it, but I could provide one if you'd 
like. But as far as how the feature would be used I was thinking along the 
following lines:

For a new project the user would select a connection profile and the 
database objects to export. The databases object DDL statement would then 
be generated to individual files and stored in the project hierarchy which 
would be similar the SQL Model hierarchy (Tables, views and routines 
folders split repeated for each schemas). 

Once created the project could then be put in a version control system 
(supplied by eclipse). This is actually one of my main goal: to provide a 
easy way of exporting the database objects and then be able to put it 
under version control.

The project structures would also be used to stored deployment scripts, 
SQL Test case, data generation plan, etc... Any scripts that would be 
related to a project.

It would also be possible to import new object to an existing project. 

I also want to add a deploy functionality. This would then deploy the 
project to a given connection profile.

In a development scenario, the developer would check out the project, make 
his modification, deploy it to test.

Of course while the deploy functionality is probably good enough for 
dev/testing it is ill suited for production deployment (especially for 
tables modification). This is why the next feature I want to develop will 
be a schema compare... But one feature at a time ;-)

Also if you see anything else that could be added to the dbproject tool 
then let me know. I am mostly developing a tool that I would use, but I am 
very much interested in what other people other people would like in a 
project functionality.

> All of the existing content and label providers that are hosted in the DSE 
> are pretty focused on the Common Navigator Framework. The reason for that 
> was that it was easy to provide additional extensions via separate plug-ins 
> to contribute various levels of the SQL model hierarchy, etc.

> That said, you should be able to do this by massaging some of the existing 
> code. If you use the ProfileSelectionDialogPage and build your own 
> ProfileSelectionComposite, you can change the styles that are passed to the 
> CommonViewer when it's created.

> The doCreateControl() method (protected void doCreateControl(Composite 
> content, boolean flag, boolean multiSelect)) can be changed to provide your 
> own checkbox styles (SWT.CHECK) and you should be able to add a selection 
> listener to the tree for SWT.CHECK events...
>           if(event.detail == SWT.CHECK)
> If that doesn't work, give me a holler and I'll try and come up with an 
> example. Hope that helps!--Fitz

Thanks for the tips. I hadn't realized that I could supply the check style 
to the common viewer. I am thinking that I could probably extend the 
common viewer and add it the ContainerCheckedTreeViewer code for handling 
the checkboxes.

This brings me to wonder if it is be possible to limit the Common 
Navigator to display only the Schemas section ? Since in this case that is 
the only thing I would need to display to the user.