I'm working on a client project (OACS4.6) which requires a
Classifieds system. The plan was to port Classifieds (/gc) from
OACS3, but I'm not sure what the best way to do it is.
Goals
- The client wants classifieds primarily for job postings.
- I'd like to build something generic that can be reused by the
OpenACS community.
- I'd like to do it near budget. That is, I have $x to build
classifieds for the customer, and I'm happy to throw in some of my
own time to make classifieds something useful for everyone. At the
same token, I can't spend the time building all sorts of wild feature
creep stuff, so I'd like to keep classifieds down to the basics for
this initial version.
I've looked at OACS3 /gc code and it is pretty simple. Big
classified_ads table that has a bunch of columns for all
sorts of uses: one_line, description, salary, location, colour,
manufacturer, size. Not every column is relevant for every use of
the classifieds system.
Question 1: Is it considered better* to have a big table with
lots of fields for every possible use, or to break this down, leaving
perhaps just one_line and description with a few hints?
*better is obviously a subjective term. With it I'm referring to
what the consensus is among the OACS decision-makers.
Question 2: What approach should I use? Options I've
considered are:
- Implement in much the same way as OACS3 /gc -- a table for
current ads, a table for revisions.
- Use the content repository and create custom content types.
I'm leaning toward the latter, but then I have to make some pretty
heavy decisions re: question 1.
If you were writing a classifieds system, how would you do
it?
Thanks.
