Re: Category question

One of the reasons I suggested the CSV was thinking about when mirrors get in on the act... but I guess the small addition of a second table isn't going to put them off :) btw, thought I didn't mention it, I'm also +1 for this and will gladly help with any changes that are chosen to be implemented... - Davey Xavier Noguer wrote:

--------- Original Message -------- From: davey@php.net To: pear-dev@lists.php.net <pear-dev@lists.php.net> Subject: Re: [PEAR-DEV] Category question Date: 18/05/03 01:54

on the DB end, you could just store a CSV list of catagories in the catagory column... in fact this is probably the best way to stop having limits on the number of catagories a package can be in. Or theres the other way of creating a second table with id,package_id,catagory_id and just cross referencing... but this is quite a bit more work (for PHP/the RDBMS) to do... and so I'd suggest using the CSV with a simple explode.

I hope we can give ourselves the luxury of having a normalized DB :) I'll wait to hear Martin's or Thomas's opinion on this, since they would have to be the ones making the actual changes.

And by changing the select box to a mutliple select box (and its name to an array) you just simply implode(',',$catagories) and insert that into the DB. - Davey Xavier Noguer wrote: &gt; BIG +1 &gt; &gt; Although this makes me think PEAR's data model will have to change: &gt; &gt; $query = &quot;INSERT INTO packages &gt; (id,name,category,license,summary,description,homepage) &gt; VALUES(?,?,?,?,?,?,?)&quot;; &gt; &gt; It assumes packages belong to just one category. &gt; &gt; --------- Original Message -------- &gt; From: Greg Beaver &lt;greg@chiaraquartet.net&gt; &gt; To: pear-dev@lists.php.net &lt;pear-dev@lists.php.net&gt; &gt; Subject: [PEAR-DEV] Category question &gt; Date: 18/05/03 00:03 &gt; &gt; &gt;&gt;Hi, &gt;&gt; &gt;&gt;I'd like to open a can of worms for future discussion :). &gt;&gt; &gt;&gt;When I'm trying to find a package, it is often difficult to figure

out

&gt;&gt;exactly which category it belongs in. Why not allow packages to

fall

&gt;&gt;into more than one category? For instance, the Tree class would &gt;&gt;logically be placed into Structures, DB, and XML since it is all

three.

>>       I would really like to see PEAR become more user-friendly,

and

&gt;&gt;this is definitely a way to do that. Perhaps documentation could

also

&gt;&gt;be generated in those categories as in: &gt;&gt; &gt;&gt;Tree docs are under Structures, and a &amp;quot;See

Structures::Tree&amp;quot;

&gt; &gt; link (like &gt; &gt;&gt;the Yellow Pages under Cab says &amp;quot;See Taxi&amp;quot;) is

in XML and DB

&gt; &gt; docs for Tree. &gt; &gt;&gt;This would certainly cut down on the questions &amp;quot;is this

in

&gt; &gt; PEAR?&amp;quot; since &gt; &gt;&gt;things would be filed under the multiple categories they belong

in.

&gt;&gt;Most packages probably fit into one category, but this would also &gt;&gt;satisfy ambiguities like template engines, which really should be &gt;&gt;categorized under both HTML and Templates, for example. This

would also

&gt;&gt;allow placing core packages under their respective categories, and

under

&gt;&gt;core (or PFC or whatever it will be called). &gt;&gt; &gt;&gt;Greg &gt;&gt; &gt;&gt; &gt;&gt;-- &gt;&gt;PEAR Development Mailing List (http://pear.php.net/) &gt;&gt;To unsubscribe, visit: http://www.php.net/unsub.php &gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; &gt; &gt; -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php