Re: Category question
| From: | Xavier Noguer | Date: | Sat, 17 May 2003 22:24:56 +0000 |
| Subject: | Re: Category question | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-16430@lists.php.net to get a copy of this message | ||
--------- 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:
> > BIG +1
> >
> > Although this makes me think PEAR's data model will have to change:
> >
> > $query = "INSERT INTO packages
> > (id,name,category,license,summary,description,homepage)
> > VALUES(?,?,?,?,?,?,?)";
> >
> > It assumes packages belong to just one category.
> >
> > --------- Original Message --------
> > From: Greg Beaver <greg@chiaraquartet.net>
> > To: pear-dev@lists.php.net <pear-dev@lists.php.net>
> > Subject: [PEAR-DEV] Category question
> > Date: 18/05/03 00:03
> >
> >
> >>Hi,
> >>
> >>I'd like to open a can of worms for future discussion :).
> >>
> >>When I'm trying to find a package, it is often difficult to figure
out
> >>exactly which category it belongs in. Why not allow packages to
fall
> >>into more than one category? For instance, the Tree class would
> >>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
> >>this is definitely a way to do that. Perhaps documentation could
also
> >>be generated in those categories as in:
> >>
> >>Tree docs are under Structures, and a &quot;See
Structures::Tree&quot;
> >
> > link (like
> >
> >>the Yellow Pages under Cab says &quot;See Taxi&quot;) is
in XML and DB
> >
> > docs for Tree.
> >
> >>This would certainly cut down on the questions &quot;is this
in
> >
> > PEAR?&quot; since
> >
> >>things would be filed under the multiple categories they belong
in.
> >>Most packages probably fit into one category, but this would also
> >>satisfy ambiguities like template engines, which really should be
> >>categorized under both HTML and Templates, for example. This
would also
> >>allow placing core packages under their respective categories, and
under
> >>core (or PFC or whatever it will be called).
> >>
> >>Greg
> >>
> >>
> >>--
> >>PEAR Development Mailing List (http://pear.php.net/)
> >>To unsubscribe, visit:
> http://www.php.net/unsub.php
> >>
> >>
> >>
> >>
> >>
> >
> >
>
>
> --
> PEAR Development Mailing List (http://pear.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>
>
>