This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 28116 - Suggesting to remove ContentDescriptor.getContent()
Summary: Suggesting to remove ContentDescriptor.getContent()
Status: RESOLVED FIXED
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Infrastructure (show other bugs)
Version: 3.x
Hardware: All All
: P1 blocker (vote)
Assignee: David Konecny
URL:
Keywords: API
: 25414 (view as bug list)
Depends on:
Blocks: 28454
  Show dependency tree
 
Reported: 2002-10-18 13:49 UTC by Petr Jiricka
Modified: 2003-12-11 14:14 UTC (History)
1 user (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Jiricka 2002-10-18 13:49:40 UTC
Currently the ContentDescriptor has method 

public abstract Object getContent() throws IOException;

The semantics of this method is not clearly defined, and 
the intention is that every module that registers a 
content type (as MIME type) will also define what objects 
this method returns for content descriptor of the given 
MIME type.

So for example, the infrastructure defines the MIME type 
for Build targets, and it also defines that for content 
descriptors with this MIME type, this method will return a 
FileSet.

The result of this is the following:
- It is not possible to use ContentDescriptors in a 
generic way, without knowing the MIME type in advance. The 
MIME type must be known.
- When working with ContentDescriptors of a particular 
MIME type, the caller always has to cast the result of 
getContent() to a particular type


I suggest removing this method, which would have the 
following implications and benefits:

- There would be one method less, so less clutter in the 
APIs.
- Every module that registers its own MIME type for 
ContentDescriptors would specify a particular subclass of 
ContentDescriptor that should be used. This subclass would 
define appropriate method in place of getContent(), e.g. 
getFileSet().
- Client code would cast the ContentDescriptor to a 
particular subtype, rather than casting the result of 
getContent().
- The particular subclass of ContentDescriptor could 
define additional methods that are relevant to the given 
content type.


So for example, instead of writing:

ContentDescriptor cd = ... // a ContentDescriptor for 
                           // a build target
FileSet fs=(FileSet)cd.getContent();

one would write the following:

ContentDescriptor cd = ... // a ContentDescriptor for 
                           // a build target
FileSet fs=((BuildTargetContentDescriptor)cd).getFileSet();
Comment 1 Svata Dedic 2002-10-18 14:00:51 UTC
I disagree. See explanation in my e-mail to George Fink posted
recently on projects-dev. The main point is that JVM typesystem should
not be used in place of value attributes.

In addition, it's not clear what your proposal solves. As you have to
know the mimetype in advance, you also have to know the tag type in
advance. What's the difference ? I would agree if the tag type bring a
new functionality, it would be a better way.
Comment 2 Vitezslav Stejskal 2002-10-18 14:28:50 UTC
I think in Petr's proposal java types aren't used as value attributes.
You still can have several MIME types for tagging semanticaly
different data but with the same accessor class. E.g. there can be
several MIME types denoting different classpath' but data which they
return are allways of the same type (instance of ClassPath).

I have another reservation to this proposal. Since java doesn't allow
multiple inheritance people will usualy end up with creating special
type - subclass of ContentDescriptor - providing accessor method to
the actual data. E.g. for basic three MIME types provided by infra
which are supposed to carry FileSet as their data there should be
something similar to Petr's BuildTargetContentDescriptor which only
provides specialized accessor to the FileSet.

I didn't realized this before, but now it seems ugly to me. Comparing
to that I am in favor of current getContent method.
Comment 3 Svata Dedic 2002-10-18 14:36:44 UTC
IMHO it does not matter, if you use types to tag (returned) values or
accessors to values. In both situation you need to introduce new
classes to distinguish (accessor to) otherwise same data.
Comment 4 Petr Jiricka 2002-10-18 16:09:28 UTC
Well, now I am thinking about whether we need 
ContentDescriptors at all. Do we ? What for ?

Comment 5 Svata Dedic 2002-10-18 22:05:38 UTC
OK, then let's all declare our own content getter classes. The one I
will declare will be

public class PathResourceProvider {
     public String getType();
     public PathResource getResource();
}

And all of us with similar getters will provide filtering capabilities
or all our clients will have to. That's exactly what ContentDescriptor
/ ContainersList do.

How is a dozen of such classes better than dozen ContentDescriptor
instances ? Although only the payload type is needed in the API, the
getters must be in the API, too.

Anyway I don't care. But if you want the change, do it NOW.
Comment 6 Vitezslav Stejskal 2002-11-06 10:32:53 UTC
We had another round of off-line discussions, here is the outcome:

1. we will have ContentDescriptor, it's useful for reasons Svata
explained in his comments above
2. we will have ContainersList and support search using MIME types 
3. we will remove generic getContents method in favor of specialized
subclasses of ContentDescriptor

In regard to #3, having Object getContent() or specialized subclass of
ContentDescriptor are equivalent ways. However, allowing sepcialized
subclasses is more extensible as the subclass can provide specialized
methods suitable for excatly this type of container (e.g. not only
accessing it's contents). The #3 doesn't affect #2 in sense of forcing
API clients to use java types for tagging particular containers. There
still can be multiple MIME types defined which support single subclass
of ContentDescriptor.
Comment 7 Vitezslav Stejskal 2002-11-06 10:33:37 UTC
*** Issue 25414 has been marked as a duplicate of this issue. ***
Comment 8 David Konecny 2002-11-07 14:37:58 UTC
Implemented in files:

Checking in nbbuild/build.xml;
/cvs/nbbuild/build.xml,v  <--  build.xml
new revision: 1.185.2.27; previous revision: 1.185.2.26
done
Processing log script arguments...
More commits to come...
Checking in java/api/build.xml;
/cvs/java/api/build.xml,v  <--  build.xml
new revision: 1.5.4.12; previous revision: 1.5.4.11
done
Processing log script arguments...
More commits to come...
Checking in
java/api/src/org/netbeans/api/java/project/CompilationUnit.java;
/cvs/java/api/src/org/netbeans/api/java/project/Attic/CompilationUnit.java,v
 <--  CompilationUnit.java
new revision: 1.1.2.4; previous revision: 1.1.2.3
done
Processing log script arguments...
More commits to come...
Checking in
java/src/org/netbeans/modules/java/JExternalCompilerGroup.java;
/cvs/java/src/org/netbeans/modules/java/JExternalCompilerGroup.java,v
 <--  JExternalCompilerGroup.java
new revision: 1.40.34.11; previous revision: 1.40.34.10
done
Processing log script arguments...
More commits to come...
Checking in
java/src/org/netbeans/modules/java/classpath/ContainerPathContent.java;
/cvs/java/src/org/netbeans/modules/java/classpath/Attic/ContainerPathContent.java,v
 <--  ContainerPathContent.java
new revision: 1.1.4.6; previous revision: 1.1.4.5
done
Checking in java/src/org/netbeans/modules/java/classpath/FolderItem.java;
/cvs/java/src/org/netbeans/modules/java/classpath/Attic/FolderItem.java,v
 <--  FolderItem.java
new revision: 1.1.4.10; previous revision: 1.1.4.9
done
Checking in
java/src/org/netbeans/modules/java/classpath/RootFolderWizard.java;
/cvs/java/src/org/netbeans/modules/java/classpath/Attic/RootFolderWizard.java,v
 <--  RootFolderWizard.java
new revision: 1.1.4.5; previous revision: 1.1.4.4
done
Processing log script arguments...
More commits to come...
Checking in
java/src/org/netbeans/modules/java/parser/ParseSourceRequest.java;
/cvs/java/src/org/netbeans/modules/java/parser/ParseSourceRequest.java,v
 <--  ParseSourceRequest.java
new revision: 1.11.10.9; previous revision: 1.11.10.8
done
Processing log script arguments...
More commits to come...
Checking in
java/src/org/netbeans/modules/java/project/CompilerOutput.java;
/cvs/java/src/org/netbeans/modules/java/project/Attic/CompilerOutput.java,v
 <--  CompilerOutput.java
new revision: 1.1.2.24; previous revision: 1.1.2.23
done
Checking in
java/src/org/netbeans/modules/java/project/CompilerOutputLook.java;
/cvs/java/src/org/netbeans/modules/java/project/Attic/CompilerOutputLook.java,v
 <--  CompilerOutputLook.java
new revision: 1.1.2.12; previous revision: 1.1.2.11
done
RCS file:
/cvs/java/src/org/netbeans/modules/java/project/Attic/JavaClasspathDescriptor.java,v
done
Checking in
java/src/org/netbeans/modules/java/project/JavaClasspathDescriptor.java;
/cvs/java/src/org/netbeans/modules/java/project/Attic/JavaClasspathDescriptor.java,v
 <--  JavaClasspathDescriptor.java
new revision: 1.1.2.1; previous revision: 1.1
done
Checking in java/src/org/netbeans/modules/java/project/JavaResource.java;
/cvs/java/src/org/netbeans/modules/java/project/Attic/JavaResource.java,v
 <--  JavaResource.java
new revision: 1.1.2.15; previous revision: 1.1.2.14
done
Checking in
java/src/org/netbeans/modules/java/project/JavaSourcesComponent.java;
/cvs/java/src/org/netbeans/modules/java/project/Attic/JavaSourcesComponent.java,v
 <--  JavaSourcesComponent.java
new revision: 1.1.2.25; previous revision: 1.1.2.24
done
Checking in
java/src/org/netbeans/modules/java/project/JavaUsageRecognizer.java;
/cvs/java/src/org/netbeans/modules/java/project/Attic/JavaUsageRecognizer.java,v
 <--  JavaUsageRecognizer.java
new revision: 1.1.2.10; previous revision: 1.1.2.9
done
Checking in
java/src/org/netbeans/modules/java/project/SourcePathProvider.java;
/cvs/java/src/org/netbeans/modules/java/project/Attic/SourcePathProvider.java,v
 <--  SourcePathProvider.java
new revision: 1.1.2.6; previous revision: 1.1.2.5
done
cvs diff: JavaClasspathDescriptor.java is a new entry, no comparison
available
Processing log script arguments...
More commits to come...
Checking in
java/src/org/netbeans/modules/java/ui/looks/OutputResource.java;
/cvs/java/src/org/netbeans/modules/java/ui/looks/Attic/OutputResource.java,v
 <--  OutputResource.java
new revision: 1.1.2.8; previous revision: 1.1.2.7
done
Processing log script arguments...
More commits to come...
RCS file:
/cvs/projects/compilation/src/org/netbeans/api/compilation/Attic/BuildTargetDescriptor.java,v
done
Checking in
projects/compilation/src/org/netbeans/api/compilation/BuildTargetDescriptor.java;
/cvs/projects/compilation/src/org/netbeans/api/compilation/Attic/BuildTargetDescriptor.java,v
 <--  BuildTargetDescriptor.java
new revision: 1.1.2.1; previous revision: 1.1
done
Checking in
projects/compilation/src/org/netbeans/api/compilation/CompilerEngine.java;
/cvs/projects/compilation/src/org/netbeans/api/compilation/Attic/CompilerEngine.java,v
 <--  CompilerEngine.java
new revision: 1.1.2.11; previous revision: 1.1.2.10
done
cvs diff: BuildTargetDescriptor.java is a new entry, no comparison
available
Processing log script arguments...
More commits to come...
Checking in
projects/compilation/src/org/netbeans/modules/compilation/BuildTargetSupport.java;
/cvs/projects/compilation/src/org/netbeans/modules/compilation/Attic/BuildTargetSupport.java,v
 <--  BuildTargetSupport.java
new revision: 1.1.2.7; previous revision: 1.1.2.6
done
Processing log script arguments...
More commits to come...
Checking in
projects/compilation/src/org/netbeans/spi/compilation/BuildTargetTransferable.java;
/cvs/projects/compilation/src/org/netbeans/spi/compilation/Attic/BuildTargetTransferable.java,v
 <--  BuildTargetTransferable.java
new revision: 1.1.2.4; previous revision: 1.1.2.3
done
Processing log script arguments...
More commits to come...
Checking in projects/core/src/org/netbeans/api/projects/BaseDirs.java;
/cvs/projects/core/src/org/netbeans/api/projects/Attic/BaseDirs.java,v
 <--  BaseDirs.java
new revision: 1.1.2.2; previous revision: 1.1.2.1
done
Checking in
projects/core/src/org/netbeans/api/projects/ContentDescriptor.java;
/cvs/projects/core/src/org/netbeans/api/projects/Attic/ContentDescriptor.java,v
 <--  ContentDescriptor.java
new revision: 1.1.2.2; previous revision: 1.1.2.1
done
Processing log script arguments...
More commits to come...
RCS file:
/cvs/projects/ide/src/org/netbeans/api/projects/ide/Attic/ResourceDescriptor.java,v
done
Checking in
projects/ide/src/org/netbeans/api/projects/ide/ResourceDescriptor.java;
/cvs/projects/ide/src/org/netbeans/api/projects/ide/Attic/ResourceDescriptor.java,v
 <--  ResourceDescriptor.java
new revision: 1.1.2.1; previous revision: 1.1
done
RCS file:
/cvs/projects/ide/src/org/netbeans/api/projects/ide/Attic/SourceDescriptor.java,v
done
Checking in
projects/ide/src/org/netbeans/api/projects/ide/SourceDescriptor.java;
/cvs/projects/ide/src/org/netbeans/api/projects/ide/Attic/SourceDescriptor.java,v
 <--  SourceDescriptor.java
new revision: 1.1.2.1; previous revision: 1.1
done
Checking in projects/ide/src/org/netbeans/api/projects/ide/Workplace.java;
/cvs/projects/ide/src/org/netbeans/api/projects/ide/Attic/Workplace.java,v
 <--  Workplace.java
new revision: 1.1.2.2; previous revision: 1.1.2.1
done
cvs diff: ResourceDescriptor.java is a new entry, no comparison available
cvs diff: SourceDescriptor.java is a new entry, no comparison available
Processing log script arguments...
More commits to come...
Checking in
projects/ide/src/org/netbeans/modules/projects/ide/DefaultContainer.java;
/cvs/projects/ide/src/org/netbeans/modules/projects/ide/Attic/DefaultContainer.java,v
 <--  DefaultContainer.java
new revision: 1.1.2.2; previous revision: 1.1.2.1
done
Processing log script arguments...
More commits to come...
Checking in
projects/ide/src/org/netbeans/modules/projects/ide/ui/looks/OutputLook.java;
/cvs/projects/ide/src/org/netbeans/modules/projects/ide/ui/looks/Attic/OutputLook.java,v
 <--  OutputLook.java
new revision: 1.1.2.2; previous revision: 1.1.2.1
done
Checking in
projects/ide/src/org/netbeans/modules/projects/ide/ui/looks/ProjectBasicLook.java;
/cvs/projects/ide/src/org/netbeans/modules/projects/ide/ui/looks/Attic/ProjectBasicLook.java,v
 <--  ProjectBasicLook.java
new revision: 1.1.2.2; previous revision: 1.1.2.1
done
Checking in
projects/ide/src/org/netbeans/modules/projects/ide/ui/looks/ResourcesLook.java;
/cvs/projects/ide/src/org/netbeans/modules/projects/ide/ui/looks/Attic/ResourcesLook.java,v
 <--  ResourcesLook.java
new revision: 1.1.2.2; previous revision: 1.1.2.1
done
Processing log script arguments...
More commits to come...
Checking in
projects/ide/src/org/netbeans/modules/projects/ide/wizards/FileChooserPanel.java;
/cvs/projects/ide/src/org/netbeans/modules/projects/ide/wizards/Attic/FileChooserPanel.java,v
 <--  FileChooserPanel.java
new revision: 1.1.2.2; previous revision: 1.1.2.1
done
Comment 9 David Konecny 2002-11-07 15:39:35 UTC
UPGRADE GUIDE:

org.netbeans.api.projects.ContentDescriptor does not contain

  public abstract Object getContent () throws java.io.IOException;

method anymore. Also definition of mime types from this class was
removed. Three new concrete content descriptor classes are defined and
modules should use these instead of the original one. These three
classes are:
	
org.netbeans.api.compilation.BuildTargetDescriptor
org.netbeans.api.projects.ide.SourceDescriptor
org.netbeans.api.projects.ide.ResourceDescriptor

All these new classes extend the ContentDescriptor and define new method

  public abstract FileSet getContent() throws java.io.IOException;

which replaces the original one from ContentDescriptor class. These
classes also redefine the mime types:

BuildTargetDescriptor.MIME_PROJECT_OUTPUT
ResourceDescriptor.MIME_PROJECT_RESOURCE
SourceDescriptor.MIME_PROJECT_SOURCE

The module writers should use these three new classes from now and
define their own content descriptors when needed.