Re: [epf-dev] Tooling: Import/Export wizard white list

[Brian Schlosser <bschloss@xxxxxxxxxx>]

I agree with your identification of
scenarios, and as I think about it more, having another extension point
is probably the cleanest way to go. I had thought about it briefly, but
dismissed it for some reason that is unclear to me now.

I've opened a bug to track the issue:
   https://bugs.eclipse.org/bugs/show_bug.cgi?id=140575

Brian Schlosser
- bschloss@xxxxxxxxxx - 512-838-0521

Kelvin Low/Cupertino/IBM@IBMUS
Sent by: epf-dev-bounces@xxxxxxxxxxx

05/05/2006 12:38 PM

Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>

To	Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
cc	epf-dev@xxxxxxxxxxx, epf-dev-bounces@xxxxxxxxxxx
Subject	Re: [epf-dev] Tooling: Import/Export wizard white list

There are 2 scenarios which we need to consider. 

1. Running EPF Composer as a standalone RCP application

We need the filtering mechanism to expose only the export and import types
that are relevant. However, to be a good citizen, we should publish our
own extension point, say "org.eclipse.epf.ui.exportWizards"
and "org.eclipse.epf.ui.importWizards"
for a plug-in to register with EPF Composer a list of export and/or import
wizards that will be made visible. The "additional" extension
point declaration can be as simple as this: 

   <extension
         point="org.eclipse.epf.ui.exportWizards">
      <wizard
            id="org.eclipse.epf.export.msp.wizards.ExportToMSProjectWizard"
      </wizard>
   </extension>

The wizard id should reference a wizard declared via the "org.eclipse.ui.exportWizards"
extension point. For example, 

   <extension
         point="org.eclipse.ui.exportWizards">
      <wizard
            id="org.eclipse.epf.export.msp.wizards.ExportToMSProjectWizard"
            class="org.eclipse.epf.export.msp.wizards.ExportToMSProjectWizard"
            name="%exportProjectTemplateWizardName"
            icon="icons/full/obj16/ProjectTemplate.gif">
         <description>
               %exportProjectTemplateWizardDescription
         </description>
      </wizard>
   </extension>

2. Running EPF Composer in an Eclipse IDE or shell

Technically, the org.eclipse.epf.rcp plug-in should not be included at
all. This will eliminate the filtering completely.


Regards, 
Kelvin 

-------------------------------------------------------------------
Kelvin Low
Software Architect
IBM Method and IC Engineering
tel:  408-342-4630
fax: 408-863-4144
email: lowk@xxxxxxxxxx

Brian Schlosser/Austin/IBM@IBMUS
Sent by: epf-dev-bounces@xxxxxxxxxxx

05/05/2006 09:16 AM

Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>

To	epf-dev@xxxxxxxxxxx
cc
Subject	[epf-dev] Tooling: Import/Export wizard white list

EPF Composer currently uses a subclass of the standard Import/Export wizards
that adds a white list of allowed Import/Export extensions. (TNGExportWizard.java
and TNGImportWizard.java) 

This hampers the Eclipse "Invitation Rule: Whenever possible let others
contribute to your contributions" In order to export data from the
library I have to get a change made to the base product. I've run across
this already, and some one else asked me about writing a plugin to export
the method contents to tabular data. Not to mention the recent additions
of MS-Project export and XML import/export. 

Here are the alternatives that I see (in order of my personal preference):
1.        Eliminate the filtering completely
2.        Make it a section in preferences so a user
could modify it 
3.        Make it a blacklist 

Number one might be to aggressive, as the additional import/export options
that would become visible maybe confusing to a novice.

Something else that could be done, but would take considerable more effort
is to do #1, but make use of the Capabilities extension points in Eclipse
to gradually reveal more advanced functions. I'm not sure if this is feasible
because it might require the plugins that contribute the import/export
options that we want to hide to implement the extension point.

Anybody else have other thoughts on this topic? 

Brian Schlosser - bschloss@xxxxxxxxxx - 512-838-0521_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev