On Sat, May 31, 2008 at 11:24 AM, Thomas N. <[EMAIL PROTECTED]> wrote:
> I had to add the following method: > > /** > * Allows for a check of the import facility before actually doing the > * import. If true is returned, then the import will be invoked by calling > * the public doFile() method of the Import class, otherwise no import is > * invoked. The import module normally returns true, but it could return > * false and call the doFile() method on it's own, which is done e.g. by > * the JavaImport after displaying a classpath dialog. > * > * @param importer the Import instance > * > * @return whether Import.doFile() should be invoked or not > */ > boolean isApprovedImport(Import importer); > > For all non-Java import modules, it is safe to return true. The problem with this is that it violates the entire purpose of the importer refactoring which was to make importers GUI independent so that they could be used with both Swing (ArgoUML) and SWT (ArgoEclipse). Additionally, if we ever do need to extend this interface, we really need to think strongly about backward compatibility since we are supposed to be supporting this API for external use and keeping it stable over time. Adding a new method to an existing manatory interface immediately obsoletes all existing modules. The compatible way of doing this would be to define a new, optional, interface that provides the additional method(s). Have you looked at the existing going independent importer settings interface? Can it be used to provide what you need? Would an additional settings type (e.g. list or list of files) help? Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
