platform-team/team3.1/problems-view.html - www.eclipse.org/eclipse - Git at Google

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
 <html>
 <head>
 <title>Generic Problems View</title>
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
 </head>

 <body>
 <h1>Generic Problems View</h1>
 <p>The purpose of this document is to present details of the solutions for the
   generic Problems view presented in <a href="logical-support.html">Enabling Logical
   Model Integration in the Eclipse Platform</a>.</p>
 <h2>Generic Views In the Eclipse Platform</h2>
 <p>There are several views in the Eclipse platform that have generic titles but
   only displays the elements associated with the Platform Resource model. For
   instance, the Problems view can only display prblems that are associated with
   file system resources. This forces other models to either associate their problems
   with file system resources or create their own view. There are several such
   views in the Eclipe Platform:</p>
 <ul>
   <li><strong>Problems view</strong>: Displays the list of problems that exist
     in the workspace. Provides links to the resource where the problem exists
     and possible to one or more solutons (through QuickFixes).</li>
   <li><strong>Bookmark view</strong>: Similar nature to the problems view.</li>
   <li><strong>Tasks view</strong>: Displays a list of tasks the user should or
     could perform.Currently, tasks are tied to resources just like problems and
     bookmarks so a similar solution could be applied to the Tasks view. However,
     one could easily argue that tasks could be associated with multiple resources
     (or no resources). This makes generalizing Task related concepts more difficult
     than that of problems and bookmarks.</li>
   <li><strong>Resource Navigator view</strong>: Displays the elements that exist
     in the workspace in a form that allows the user to navigate the workspace.
     There is work in the WTP project on a generic navigator and the rumor is that
     this may get pushed down to the Platform sometime after 3.1.</li>
 </ul>
 <p>The Search view already has support for searches from different model domains.
   This comes in two forms:</p>
 <ul>
   <li>The Platform has pluggable support for search types. Some example search
     types are File Search, Java Search, Plugin Search and NLS Search. Each search
     type, when executed, adds a custom search result page to the search view.</li>
   <li>Some search types support participation. For instance the Java Search allows
     particpants to be added to Java searches.</li>
 </ul>
 <p>The main issue in generalizing these views is determining the best way to combine
   the problems, tasks or elements from multiple models in the same view. There
   are two obvious ways to do this:</p>
 <ul>
   <li>show the problems, tasks or elements from all models in the same view.
     <ul>
       <li>This is the approach taken in the generic navigator proposal</li>
       <li>Need grouping or filtering APIs to provide scalability</li>
     </ul>
   </li>
   <li>provide a paged view where each page shows the problems, tasks or elements
     from a particular model
     <ul>
       <li>This is the approach taken by the Search view</li>
       <li>Still needs grouping or filtering to deal with scalability</li>
     </ul>
   </li>
 </ul>
 <p>Each of these has their advantages and disadvantages. A single view frees the
   user from selecting which model to look at but such a view does not scale well.
   A paged view provides a means of top level filtering by model (advantage or
   disadvantage?) but can still have scalability issues. The nature of each particular
   view will dictate which approach is more suitable. This document focuses on
   the Problems view as it was identified in the scenarios presented in <a href="logical-support.html">Enabling
   Logical Model Integration in the Eclipse Platform</a>.</p>
 <h2>The Problems View</h2>
 <p>This view seems to be of most interest to modeling tools built on top of the
   Platform since it deals with helping the user correct model inconsistencies.
   For this reason, we will outline the beginnings of a possible solution here.
 </p>
 <p>Based on several discussions on this topic, the following is a list of the
   desired properties of a generic Problems view.</p>
 <ul>
   <li>All the problems appear in a single view (i.e. not multiple pages) but are
     not tied to resource markers
     <ul>
       <li>Requires a generic problem API</li>
     </ul>
   </li>
   <li>Support filtering
     <ul>
       <li>include/exclude problems from different domains</li>
       <li>by severity</li>
       <li>domain specific</li>
       <li>selection</li>
     </ul>
   </li>
   <li>Support grouping
     <ul>
       <li> arrange problems hierarchically. e.g. problems grouped by logical or
         physical resource</li>
     </ul>
   </li>
   <li>Sorting
     <ul>
       <li>sorting across domains
         <ul>
           <li>severity</li>
           <li>description</li>
         </ul>
       </li>
       <li>domain specific</li>
     </ul>
   </li>
   <li>Actions
     <ul>
       <li>Goto action, Show in and QuickFix support that performs an action appropriate
         for the selected problem</li>
     </ul>
   </li>
   <li>Efficient addition and removal of problems
     <ul>
       <li>problems may be removed/added one at a time or a domain at a time</li>
     </ul>
   </li>
   <li>Display information appropriate for problem type
     <ul>
       <li>generic columns (severity, description, resource, path, location in
         resource)</li>
       <li>allow user configuration of displayed columns (included domain specific
         columns)</li>
       <li>support separate pane that shows details of selected problem or alternate
         views of the problem (i.e. problem dependency graph)</li>
     </ul>
   </li>
 </ul>
 <p>&nbsp;</p>
 <h2>Status</h2>
 <p>Here is the status of this work as of 3.1 M5</p>
 <p>Generic Views: This needs to be driven by model owners with help from Platform
   committers. Until model teams step forward and dedicate resources to this problem,
   it is unlikely that work will progress.</p>
 <p>&nbsp;</p>
 </body>
 </html>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
	<html>
	<head>
	<title>Generic Problems View</title>
	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
	</head>

	<body>
	<h1>Generic Problems View</h1>
	<p>The purpose of this document is to present details of the solutions for the
	generic Problems view presented in <a href="logical-support.html">Enabling Logical
	Model Integration in the Eclipse Platform</a>.</p>
	<h2>Generic Views In the Eclipse Platform</h2>
	<p>There are several views in the Eclipse platform that have generic titles but
	only displays the elements associated with the Platform Resource model. For
	instance, the Problems view can only display prblems that are associated with
	file system resources. This forces other models to either associate their problems
	with file system resources or create their own view. There are several such
	views in the Eclipe Platform:</p>
	<ul>
	<li><strong>Problems view</strong>: Displays the list of problems that exist
	in the workspace. Provides links to the resource where the problem exists
	and possible to one or more solutons (through QuickFixes).</li>
	<li><strong>Bookmark view</strong>: Similar nature to the problems view.</li>
	<li><strong>Tasks view</strong>: Displays a list of tasks the user should or
	could perform.Currently, tasks are tied to resources just like problems and
	bookmarks so a similar solution could be applied to the Tasks view. However,
	one could easily argue that tasks could be associated with multiple resources
	(or no resources). This makes generalizing Task related concepts more difficult
	than that of problems and bookmarks.</li>
	<li><strong>Resource Navigator view</strong>: Displays the elements that exist
	in the workspace in a form that allows the user to navigate the workspace.
	There is work in the WTP project on a generic navigator and the rumor is that
	this may get pushed down to the Platform sometime after 3.1.</li>
	</ul>
	<p>The Search view already has support for searches from different model domains.
	This comes in two forms:</p>
	<ul>
	<li>The Platform has pluggable support for search types. Some example search
	types are File Search, Java Search, Plugin Search and NLS Search. Each search
	type, when executed, adds a custom search result page to the search view.</li>
	<li>Some search types support participation. For instance the Java Search allows
	particpants to be added to Java searches.</li>
	</ul>
	<p>The main issue in generalizing these views is determining the best way to combine
	the problems, tasks or elements from multiple models in the same view. There
	are two obvious ways to do this:</p>
	<ul>
	<li>show the problems, tasks or elements from all models in the same view.
	<ul>
	<li>This is the approach taken in the generic navigator proposal</li>
	<li>Need grouping or filtering APIs to provide scalability</li>
	</ul>
	</li>
	<li>provide a paged view where each page shows the problems, tasks or elements
	from a particular model
	<ul>
	<li>This is the approach taken by the Search view</li>
	<li>Still needs grouping or filtering to deal with scalability</li>
	</ul>
	</li>
	</ul>
	<p>Each of these has their advantages and disadvantages. A single view frees the
	user from selecting which model to look at but such a view does not scale well.
	A paged view provides a means of top level filtering by model (advantage or
	disadvantage?) but can still have scalability issues. The nature of each particular
	view will dictate which approach is more suitable. This document focuses on
	the Problems view as it was identified in the scenarios presented in <a href="logical-support.html">Enabling
	Logical Model Integration in the Eclipse Platform</a>.</p>
	<h2>The Problems View</h2>
	<p>This view seems to be of most interest to modeling tools built on top of the
	Platform since it deals with helping the user correct model inconsistencies.
	For this reason, we will outline the beginnings of a possible solution here.
	</p>
	<p>Based on several discussions on this topic, the following is a list of the
	desired properties of a generic Problems view.</p>
	<ul>
	<li>All the problems appear in a single view (i.e. not multiple pages) but are
	not tied to resource markers
	<ul>
	<li>Requires a generic problem API</li>
	</ul>
	</li>
	<li>Support filtering
	<ul>
	<li>include/exclude problems from different domains</li>
	<li>by severity</li>
	<li>domain specific</li>
	<li>selection</li>
	</ul>
	</li>
	<li>Support grouping
	<ul>
	<li> arrange problems hierarchically. e.g. problems grouped by logical or
	physical resource</li>
	</ul>
	</li>
	<li>Sorting
	<ul>
	<li>sorting across domains
	<ul>
	<li>severity</li>
	<li>description</li>
	</ul>
	</li>
	<li>domain specific</li>
	</ul>
	</li>
	<li>Actions
	<ul>
	<li>Goto action, Show in and QuickFix support that performs an action appropriate
	for the selected problem</li>
	</ul>
	</li>
	<li>Efficient addition and removal of problems
	<ul>
	<li>problems may be removed/added one at a time or a domain at a time</li>
	</ul>
	</li>
	<li>Display information appropriate for problem type
	<ul>
	<li>generic columns (severity, description, resource, path, location in
	resource)</li>
	<li>allow user configuration of displayed columns (included domain specific
	columns)</li>
	<li>support separate pane that shows details of selected problem or alternate
	views of the problem (i.e. problem dependency graph)</li>
	</ul>
	</li>
	</ul>
	<p> </p>
	<h2>Status</h2>
	<p>Here is the status of this work as of 3.1 M5</p>
	<p>Generic Views: This needs to be driven by model owners with help from Platform
	committers. Until model teams step forward and dedicate resources to this problem,
	it is unlikely that work will progress.</p>
	<p> </p>
	</body>
	</html>