<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Maxwell Kanat-Alexander wrote:
<blockquote cite="mid1106652810.10792.1.camel@max.localdomain"
type="cite">
<pre wrap="">On Tue, 2005-01-25 at 07:28 +0200, Vlad Dascalu wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I agree with Myk. The FAC proposal makes more sense for me, from all
points of view.
</pre>
</blockquote>
<pre wrap=""><!---->
I also used to think so.
But if we want people to be able to write "plugins" for Bugzilla,
Fields-As-Rows makes much more sense.
</pre>
</blockquote>
Plugins can be roughly divided into three categories:<br>
<ul>
<li>add no new fields (NNF), just manipulate existing ones (f.e. a
plugin that added a "checked in" comment and resolved bugs "FIXED" when
a patch on them was checked into a source control system);<br>
</li>
<li>add new generic fields (NGF) that don't need to be manipulated
specially and can be implemented using custom fields;<br>
</li>
<li>add new special fields (NSF) that need to be manipulated
specially and cannot be implemented using custom fields (f.e. <a
href="http://sourceforge.net/projects/testrunner/">Test Runner</a>);<br>
</li>
</ul>
Of these, only NGF plugins can use custom fields, and if a plugin just
creates a custom field and then lets the generic custom field code
handle interaction with it, then why take the trouble to make it a
plugin? It'd be much easier for installations that want the
functionality to just define the custom field themselves using whatever
interface we develop for managing custom fields.<br>
<br>
I think very few, if any, plugins will create custom fields. But even
if some did (f.e. a plugin that created a bunch of related custom
fields which would otherwise be burdensome to create by hand via the
interface, or a plugin which reused most generic custom fields code but
with a few special tweaks), why does FAD make more sense for them?
Real columns are as easy to create programmatically, keep plugin data
more separate from standard and installation-defined custom field data,
and can be made more secure if necessary (by giving plugins a MySQL
account that only permitted write access to its own tables).<br>
<br>
-myk<br>
<br>
</body>
</html>